Why is the size of a directory either 0 or 4096?
$ ls -l
total 28
drwxrwxrwx 1 t t 4096 May 8 2018 dir1
drwxrwxrwx 1 t t 0 Mar 12 2015 dir2
drwxrwxrwx 1 t t 4096 Jan 17 2014 dir3
drwxrwxrwx 1 t t 4096 Jun 12 2017 dir4
drwxrwxrwx 1 t t 0 Aug 24 2012 dir5
Why is the size of a directory either 0 or 4096?
Is the size of a directory 0 because the entries in it can fit into its inode?
Is the size of a directory not 0 because the entries in it can't fit into its inode and thus need some data block(s)?
Why is the nonzero size of a directory always 4096?
Thanks.
Note my observation is the same in ext4 filesystem and in NTFS filesystem. Does it mean both filesystem types implement directories in a similar way?
filesystems directory ext4 ntfs
add a comment |
$ ls -l
total 28
drwxrwxrwx 1 t t 4096 May 8 2018 dir1
drwxrwxrwx 1 t t 0 Mar 12 2015 dir2
drwxrwxrwx 1 t t 4096 Jan 17 2014 dir3
drwxrwxrwx 1 t t 4096 Jun 12 2017 dir4
drwxrwxrwx 1 t t 0 Aug 24 2012 dir5
Why is the size of a directory either 0 or 4096?
Is the size of a directory 0 because the entries in it can fit into its inode?
Is the size of a directory not 0 because the entries in it can't fit into its inode and thus need some data block(s)?
Why is the nonzero size of a directory always 4096?
Thanks.
Note my observation is the same in ext4 filesystem and in NTFS filesystem. Does it mean both filesystem types implement directories in a similar way?
filesystems directory ext4 ntfs
1
They report similar size doesn't mean they are implemented similarly... How do you think like that... The reported size strongly depents on filesystem implementation, mostly meaningless, you can't conclude that the entries fit or not fit into inode data area just from the reported size. it's logic error. since at least you need to know the implementation of this filesystem.
– 炸鱼薯条德里克
1 hour ago
1
FWIW, it's not. Put enough files into the directory, and you'll see the size go up (probably in increments of of 4096 – a brief poke at my drive gave me 16384 (4×4096) and 69632 (17×4096) as other possible values.
– Ulrich Schwarz
1 hour ago
Possible duplicate of What does size of a directory mean in output of 'ls -l' command?
– Olorin
45 mins ago
add a comment |
$ ls -l
total 28
drwxrwxrwx 1 t t 4096 May 8 2018 dir1
drwxrwxrwx 1 t t 0 Mar 12 2015 dir2
drwxrwxrwx 1 t t 4096 Jan 17 2014 dir3
drwxrwxrwx 1 t t 4096 Jun 12 2017 dir4
drwxrwxrwx 1 t t 0 Aug 24 2012 dir5
Why is the size of a directory either 0 or 4096?
Is the size of a directory 0 because the entries in it can fit into its inode?
Is the size of a directory not 0 because the entries in it can't fit into its inode and thus need some data block(s)?
Why is the nonzero size of a directory always 4096?
Thanks.
Note my observation is the same in ext4 filesystem and in NTFS filesystem. Does it mean both filesystem types implement directories in a similar way?
filesystems directory ext4 ntfs
$ ls -l
total 28
drwxrwxrwx 1 t t 4096 May 8 2018 dir1
drwxrwxrwx 1 t t 0 Mar 12 2015 dir2
drwxrwxrwx 1 t t 4096 Jan 17 2014 dir3
drwxrwxrwx 1 t t 4096 Jun 12 2017 dir4
drwxrwxrwx 1 t t 0 Aug 24 2012 dir5
Why is the size of a directory either 0 or 4096?
Is the size of a directory 0 because the entries in it can fit into its inode?
Is the size of a directory not 0 because the entries in it can't fit into its inode and thus need some data block(s)?
Why is the nonzero size of a directory always 4096?
Thanks.
Note my observation is the same in ext4 filesystem and in NTFS filesystem. Does it mean both filesystem types implement directories in a similar way?
filesystems directory ext4 ntfs
filesystems directory ext4 ntfs
edited 1 hour ago
Tim
asked 1 hour ago
TimTim
27.3k78264473
27.3k78264473
1
They report similar size doesn't mean they are implemented similarly... How do you think like that... The reported size strongly depents on filesystem implementation, mostly meaningless, you can't conclude that the entries fit or not fit into inode data area just from the reported size. it's logic error. since at least you need to know the implementation of this filesystem.
– 炸鱼薯条德里克
1 hour ago
1
FWIW, it's not. Put enough files into the directory, and you'll see the size go up (probably in increments of of 4096 – a brief poke at my drive gave me 16384 (4×4096) and 69632 (17×4096) as other possible values.
– Ulrich Schwarz
1 hour ago
Possible duplicate of What does size of a directory mean in output of 'ls -l' command?
– Olorin
45 mins ago
add a comment |
1
They report similar size doesn't mean they are implemented similarly... How do you think like that... The reported size strongly depents on filesystem implementation, mostly meaningless, you can't conclude that the entries fit or not fit into inode data area just from the reported size. it's logic error. since at least you need to know the implementation of this filesystem.
– 炸鱼薯条德里克
1 hour ago
1
FWIW, it's not. Put enough files into the directory, and you'll see the size go up (probably in increments of of 4096 – a brief poke at my drive gave me 16384 (4×4096) and 69632 (17×4096) as other possible values.
– Ulrich Schwarz
1 hour ago
Possible duplicate of What does size of a directory mean in output of 'ls -l' command?
– Olorin
45 mins ago
1
1
They report similar size doesn't mean they are implemented similarly... How do you think like that... The reported size strongly depents on filesystem implementation, mostly meaningless, you can't conclude that the entries fit or not fit into inode data area just from the reported size. it's logic error. since at least you need to know the implementation of this filesystem.
– 炸鱼薯条德里克
1 hour ago
They report similar size doesn't mean they are implemented similarly... How do you think like that... The reported size strongly depents on filesystem implementation, mostly meaningless, you can't conclude that the entries fit or not fit into inode data area just from the reported size. it's logic error. since at least you need to know the implementation of this filesystem.
– 炸鱼薯条德里克
1 hour ago
1
1
FWIW, it's not. Put enough files into the directory, and you'll see the size go up (probably in increments of of 4096 – a brief poke at my drive gave me 16384 (4×4096) and 69632 (17×4096) as other possible values.
– Ulrich Schwarz
1 hour ago
FWIW, it's not. Put enough files into the directory, and you'll see the size go up (probably in increments of of 4096 – a brief poke at my drive gave me 16384 (4×4096) and 69632 (17×4096) as other possible values.
– Ulrich Schwarz
1 hour ago
Possible duplicate of What does size of a directory mean in output of 'ls -l' command?
– Olorin
45 mins ago
Possible duplicate of What does size of a directory mean in output of 'ls -l' command?
– Olorin
45 mins ago
add a comment |
2 Answers
2
active
oldest
votes
Some filesystems have some space in the inode that can be used to hold very small directories. But once the directory is large enough to not fit in that area, the OS will allocate an entire file allocation unit, which in your case is apparently 4096 bytes.
On ext4, this is enabled with the inline_data ext4 option.
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inline_Directories
add a comment |
About 4096
To quote Terry Wang's answer:
A directory is just a special file which contains an array of filenames and inode numbers. When the directory was created, the file system allocated 1 inode to the directory with a "filename" (dir name in fact). The inode points to a single data block (minimum overhead), which is 4096 bytes.
Directories can grow larger than 4096, and one of the peculiar "bugs" of ext4 filesystem which did not receive much priority yet is that after directory information has outgrown 4096 bytes, that number is not decremented if files are removed. And probably the big news flash is that how information is allocated for a directory depends on the filesystem and even the options which are enabled/disabled( source ), so the special number 4096 is specific to ext4 in this case, but could be something else on other filesystems such as UFS for example.
Note, however, Terry's talking about inode which represents directory, directory itself being a dirent in parent directory. Initial directory contents are dirents or links .
and ..
About 0
The ext4 filesystem defaults to creating directories ( even if empty ) with 4096 bytes allocation. That's the key. According to ServerFault and Arch Linux forum when directory shows as 0 in size it means the directory is located or hosts a filesystem other than ext4.
And this is true of virtual filesystems (which effectively aren't physical on-disk filesystems, but rather are an interface exposed by kernel and are contained in memory):
$ ls -ld /proc /sys
dr-xr-xr-x 243 root root 0 Feb 24 13:57 /proc
dr-xr-xr-x 13 root root 0 Feb 26 14:42 /sys
1
That "bug" of ext4 was in ext, ext2, ext3, ufs, and a lot of other unix filesystem formats. It's not a bug, it's the lack of an advanced feature of a few filesystem formats.
– Ed Grimm
49 mins ago
I think most non-directory is also reported as size 0 on procfs or sysfs.
– 炸鱼薯条德里克
48 mins ago
@EdGrimm Please look at the linked post, which features Theodore Tso's quote (who is one of the developers of ext4 ). It's not so much that there's lack of features - it can be implemented, but this has not received high priority from the developers.
– Sergiy Kolodyazhnyy
46 mins ago
@炸鱼薯条德里克 Yes, that's correct. Because that data literally occupies 0 blocks of disk space.
– Sergiy Kolodyazhnyy
46 mins ago
@SergiyKolodyazhnyy He didn't say whether it was a feature or a bug. He just said that ext4 doesn't do it. I think there's a few filesystems that supposedly do it that's not on his list, but there really aren't many that do, and they're all newer than ext2. Before them, it wasn't a feature that people particularly expected of filesystems because nobody did it. To get it added as a feature, it needs to be on the extn priority list, where n >=4.
– Ed Grimm
38 mins ago
|
show 1 more comment
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f503048%2fwhy-is-the-size-of-a-directory-either-0-or-4096%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Some filesystems have some space in the inode that can be used to hold very small directories. But once the directory is large enough to not fit in that area, the OS will allocate an entire file allocation unit, which in your case is apparently 4096 bytes.
On ext4, this is enabled with the inline_data ext4 option.
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inline_Directories
add a comment |
Some filesystems have some space in the inode that can be used to hold very small directories. But once the directory is large enough to not fit in that area, the OS will allocate an entire file allocation unit, which in your case is apparently 4096 bytes.
On ext4, this is enabled with the inline_data ext4 option.
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inline_Directories
add a comment |
Some filesystems have some space in the inode that can be used to hold very small directories. But once the directory is large enough to not fit in that area, the OS will allocate an entire file allocation unit, which in your case is apparently 4096 bytes.
On ext4, this is enabled with the inline_data ext4 option.
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inline_Directories
Some filesystems have some space in the inode that can be used to hold very small directories. But once the directory is large enough to not fit in that area, the OS will allocate an entire file allocation unit, which in your case is apparently 4096 bytes.
On ext4, this is enabled with the inline_data ext4 option.
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inline_Directories
edited 51 mins ago
answered 1 hour ago
Ed GrimmEd Grimm
3837
3837
add a comment |
add a comment |
About 4096
To quote Terry Wang's answer:
A directory is just a special file which contains an array of filenames and inode numbers. When the directory was created, the file system allocated 1 inode to the directory with a "filename" (dir name in fact). The inode points to a single data block (minimum overhead), which is 4096 bytes.
Directories can grow larger than 4096, and one of the peculiar "bugs" of ext4 filesystem which did not receive much priority yet is that after directory information has outgrown 4096 bytes, that number is not decremented if files are removed. And probably the big news flash is that how information is allocated for a directory depends on the filesystem and even the options which are enabled/disabled( source ), so the special number 4096 is specific to ext4 in this case, but could be something else on other filesystems such as UFS for example.
Note, however, Terry's talking about inode which represents directory, directory itself being a dirent in parent directory. Initial directory contents are dirents or links .
and ..
About 0
The ext4 filesystem defaults to creating directories ( even if empty ) with 4096 bytes allocation. That's the key. According to ServerFault and Arch Linux forum when directory shows as 0 in size it means the directory is located or hosts a filesystem other than ext4.
And this is true of virtual filesystems (which effectively aren't physical on-disk filesystems, but rather are an interface exposed by kernel and are contained in memory):
$ ls -ld /proc /sys
dr-xr-xr-x 243 root root 0 Feb 24 13:57 /proc
dr-xr-xr-x 13 root root 0 Feb 26 14:42 /sys
1
That "bug" of ext4 was in ext, ext2, ext3, ufs, and a lot of other unix filesystem formats. It's not a bug, it's the lack of an advanced feature of a few filesystem formats.
– Ed Grimm
49 mins ago
I think most non-directory is also reported as size 0 on procfs or sysfs.
– 炸鱼薯条德里克
48 mins ago
@EdGrimm Please look at the linked post, which features Theodore Tso's quote (who is one of the developers of ext4 ). It's not so much that there's lack of features - it can be implemented, but this has not received high priority from the developers.
– Sergiy Kolodyazhnyy
46 mins ago
@炸鱼薯条德里克 Yes, that's correct. Because that data literally occupies 0 blocks of disk space.
– Sergiy Kolodyazhnyy
46 mins ago
@SergiyKolodyazhnyy He didn't say whether it was a feature or a bug. He just said that ext4 doesn't do it. I think there's a few filesystems that supposedly do it that's not on his list, but there really aren't many that do, and they're all newer than ext2. Before them, it wasn't a feature that people particularly expected of filesystems because nobody did it. To get it added as a feature, it needs to be on the extn priority list, where n >=4.
– Ed Grimm
38 mins ago
|
show 1 more comment
About 4096
To quote Terry Wang's answer:
A directory is just a special file which contains an array of filenames and inode numbers. When the directory was created, the file system allocated 1 inode to the directory with a "filename" (dir name in fact). The inode points to a single data block (minimum overhead), which is 4096 bytes.
Directories can grow larger than 4096, and one of the peculiar "bugs" of ext4 filesystem which did not receive much priority yet is that after directory information has outgrown 4096 bytes, that number is not decremented if files are removed. And probably the big news flash is that how information is allocated for a directory depends on the filesystem and even the options which are enabled/disabled( source ), so the special number 4096 is specific to ext4 in this case, but could be something else on other filesystems such as UFS for example.
Note, however, Terry's talking about inode which represents directory, directory itself being a dirent in parent directory. Initial directory contents are dirents or links .
and ..
About 0
The ext4 filesystem defaults to creating directories ( even if empty ) with 4096 bytes allocation. That's the key. According to ServerFault and Arch Linux forum when directory shows as 0 in size it means the directory is located or hosts a filesystem other than ext4.
And this is true of virtual filesystems (which effectively aren't physical on-disk filesystems, but rather are an interface exposed by kernel and are contained in memory):
$ ls -ld /proc /sys
dr-xr-xr-x 243 root root 0 Feb 24 13:57 /proc
dr-xr-xr-x 13 root root 0 Feb 26 14:42 /sys
1
That "bug" of ext4 was in ext, ext2, ext3, ufs, and a lot of other unix filesystem formats. It's not a bug, it's the lack of an advanced feature of a few filesystem formats.
– Ed Grimm
49 mins ago
I think most non-directory is also reported as size 0 on procfs or sysfs.
– 炸鱼薯条德里克
48 mins ago
@EdGrimm Please look at the linked post, which features Theodore Tso's quote (who is one of the developers of ext4 ). It's not so much that there's lack of features - it can be implemented, but this has not received high priority from the developers.
– Sergiy Kolodyazhnyy
46 mins ago
@炸鱼薯条德里克 Yes, that's correct. Because that data literally occupies 0 blocks of disk space.
– Sergiy Kolodyazhnyy
46 mins ago
@SergiyKolodyazhnyy He didn't say whether it was a feature or a bug. He just said that ext4 doesn't do it. I think there's a few filesystems that supposedly do it that's not on his list, but there really aren't many that do, and they're all newer than ext2. Before them, it wasn't a feature that people particularly expected of filesystems because nobody did it. To get it added as a feature, it needs to be on the extn priority list, where n >=4.
– Ed Grimm
38 mins ago
|
show 1 more comment
About 4096
To quote Terry Wang's answer:
A directory is just a special file which contains an array of filenames and inode numbers. When the directory was created, the file system allocated 1 inode to the directory with a "filename" (dir name in fact). The inode points to a single data block (minimum overhead), which is 4096 bytes.
Directories can grow larger than 4096, and one of the peculiar "bugs" of ext4 filesystem which did not receive much priority yet is that after directory information has outgrown 4096 bytes, that number is not decremented if files are removed. And probably the big news flash is that how information is allocated for a directory depends on the filesystem and even the options which are enabled/disabled( source ), so the special number 4096 is specific to ext4 in this case, but could be something else on other filesystems such as UFS for example.
Note, however, Terry's talking about inode which represents directory, directory itself being a dirent in parent directory. Initial directory contents are dirents or links .
and ..
About 0
The ext4 filesystem defaults to creating directories ( even if empty ) with 4096 bytes allocation. That's the key. According to ServerFault and Arch Linux forum when directory shows as 0 in size it means the directory is located or hosts a filesystem other than ext4.
And this is true of virtual filesystems (which effectively aren't physical on-disk filesystems, but rather are an interface exposed by kernel and are contained in memory):
$ ls -ld /proc /sys
dr-xr-xr-x 243 root root 0 Feb 24 13:57 /proc
dr-xr-xr-x 13 root root 0 Feb 26 14:42 /sys
About 4096
To quote Terry Wang's answer:
A directory is just a special file which contains an array of filenames and inode numbers. When the directory was created, the file system allocated 1 inode to the directory with a "filename" (dir name in fact). The inode points to a single data block (minimum overhead), which is 4096 bytes.
Directories can grow larger than 4096, and one of the peculiar "bugs" of ext4 filesystem which did not receive much priority yet is that after directory information has outgrown 4096 bytes, that number is not decremented if files are removed. And probably the big news flash is that how information is allocated for a directory depends on the filesystem and even the options which are enabled/disabled( source ), so the special number 4096 is specific to ext4 in this case, but could be something else on other filesystems such as UFS for example.
Note, however, Terry's talking about inode which represents directory, directory itself being a dirent in parent directory. Initial directory contents are dirents or links .
and ..
About 0
The ext4 filesystem defaults to creating directories ( even if empty ) with 4096 bytes allocation. That's the key. According to ServerFault and Arch Linux forum when directory shows as 0 in size it means the directory is located or hosts a filesystem other than ext4.
And this is true of virtual filesystems (which effectively aren't physical on-disk filesystems, but rather are an interface exposed by kernel and are contained in memory):
$ ls -ld /proc /sys
dr-xr-xr-x 243 root root 0 Feb 24 13:57 /proc
dr-xr-xr-x 13 root root 0 Feb 26 14:42 /sys
edited 9 mins ago
answered 56 mins ago
Sergiy KolodyazhnyySergiy Kolodyazhnyy
10.4k42663
10.4k42663
1
That "bug" of ext4 was in ext, ext2, ext3, ufs, and a lot of other unix filesystem formats. It's not a bug, it's the lack of an advanced feature of a few filesystem formats.
– Ed Grimm
49 mins ago
I think most non-directory is also reported as size 0 on procfs or sysfs.
– 炸鱼薯条德里克
48 mins ago
@EdGrimm Please look at the linked post, which features Theodore Tso's quote (who is one of the developers of ext4 ). It's not so much that there's lack of features - it can be implemented, but this has not received high priority from the developers.
– Sergiy Kolodyazhnyy
46 mins ago
@炸鱼薯条德里克 Yes, that's correct. Because that data literally occupies 0 blocks of disk space.
– Sergiy Kolodyazhnyy
46 mins ago
@SergiyKolodyazhnyy He didn't say whether it was a feature or a bug. He just said that ext4 doesn't do it. I think there's a few filesystems that supposedly do it that's not on his list, but there really aren't many that do, and they're all newer than ext2. Before them, it wasn't a feature that people particularly expected of filesystems because nobody did it. To get it added as a feature, it needs to be on the extn priority list, where n >=4.
– Ed Grimm
38 mins ago
|
show 1 more comment
1
That "bug" of ext4 was in ext, ext2, ext3, ufs, and a lot of other unix filesystem formats. It's not a bug, it's the lack of an advanced feature of a few filesystem formats.
– Ed Grimm
49 mins ago
I think most non-directory is also reported as size 0 on procfs or sysfs.
– 炸鱼薯条德里克
48 mins ago
@EdGrimm Please look at the linked post, which features Theodore Tso's quote (who is one of the developers of ext4 ). It's not so much that there's lack of features - it can be implemented, but this has not received high priority from the developers.
– Sergiy Kolodyazhnyy
46 mins ago
@炸鱼薯条德里克 Yes, that's correct. Because that data literally occupies 0 blocks of disk space.
– Sergiy Kolodyazhnyy
46 mins ago
@SergiyKolodyazhnyy He didn't say whether it was a feature or a bug. He just said that ext4 doesn't do it. I think there's a few filesystems that supposedly do it that's not on his list, but there really aren't many that do, and they're all newer than ext2. Before them, it wasn't a feature that people particularly expected of filesystems because nobody did it. To get it added as a feature, it needs to be on the extn priority list, where n >=4.
– Ed Grimm
38 mins ago
1
1
That "bug" of ext4 was in ext, ext2, ext3, ufs, and a lot of other unix filesystem formats. It's not a bug, it's the lack of an advanced feature of a few filesystem formats.
– Ed Grimm
49 mins ago
That "bug" of ext4 was in ext, ext2, ext3, ufs, and a lot of other unix filesystem formats. It's not a bug, it's the lack of an advanced feature of a few filesystem formats.
– Ed Grimm
49 mins ago
I think most non-directory is also reported as size 0 on procfs or sysfs.
– 炸鱼薯条德里克
48 mins ago
I think most non-directory is also reported as size 0 on procfs or sysfs.
– 炸鱼薯条德里克
48 mins ago
@EdGrimm Please look at the linked post, which features Theodore Tso's quote (who is one of the developers of ext4 ). It's not so much that there's lack of features - it can be implemented, but this has not received high priority from the developers.
– Sergiy Kolodyazhnyy
46 mins ago
@EdGrimm Please look at the linked post, which features Theodore Tso's quote (who is one of the developers of ext4 ). It's not so much that there's lack of features - it can be implemented, but this has not received high priority from the developers.
– Sergiy Kolodyazhnyy
46 mins ago
@炸鱼薯条德里克 Yes, that's correct. Because that data literally occupies 0 blocks of disk space.
– Sergiy Kolodyazhnyy
46 mins ago
@炸鱼薯条德里克 Yes, that's correct. Because that data literally occupies 0 blocks of disk space.
– Sergiy Kolodyazhnyy
46 mins ago
@SergiyKolodyazhnyy He didn't say whether it was a feature or a bug. He just said that ext4 doesn't do it. I think there's a few filesystems that supposedly do it that's not on his list, but there really aren't many that do, and they're all newer than ext2. Before them, it wasn't a feature that people particularly expected of filesystems because nobody did it. To get it added as a feature, it needs to be on the extn priority list, where n >=4.
– Ed Grimm
38 mins ago
@SergiyKolodyazhnyy He didn't say whether it was a feature or a bug. He just said that ext4 doesn't do it. I think there's a few filesystems that supposedly do it that's not on his list, but there really aren't many that do, and they're all newer than ext2. Before them, it wasn't a feature that people particularly expected of filesystems because nobody did it. To get it added as a feature, it needs to be on the extn priority list, where n >=4.
– Ed Grimm
38 mins ago
|
show 1 more comment
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f503048%2fwhy-is-the-size-of-a-directory-either-0-or-4096%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
They report similar size doesn't mean they are implemented similarly... How do you think like that... The reported size strongly depents on filesystem implementation, mostly meaningless, you can't conclude that the entries fit or not fit into inode data area just from the reported size. it's logic error. since at least you need to know the implementation of this filesystem.
– 炸鱼薯条德里克
1 hour ago
1
FWIW, it's not. Put enough files into the directory, and you'll see the size go up (probably in increments of of 4096 – a brief poke at my drive gave me 16384 (4×4096) and 69632 (17×4096) as other possible values.
– Ulrich Schwarz
1 hour ago
Possible duplicate of What does size of a directory mean in output of 'ls -l' command?
– Olorin
45 mins ago