Why is the size of a directory either 0 or 4096? [duplicate]What does size of a directory mean in output of...

Does a paladin have to announce that they're using Divine Smite before attacking?

Stuck on a Geometry Puzzle

Plausible reason for gold-digging ant

When obtaining gender reassignment/plastic surgery overseas, is an emergency travel document required to return home?

How can 若い時 and ずっと work in this sentence?

Is there an expiration time for free invocations?

What is a good reason for every spaceship to carry a weapon on board?

What language shall they sing in?

Why avoid shared user accounts?

A starship is travelling at 0.9c and collides with a small rock. Will it leave a clean hole through, or will more happen?

What makes papers publishable in top-tier journals?

Does the ditching switch allow an A320 to float indefinitely?

Existence of Riemann surface, holomorphic maps

How do you voice extended chords?

Coworker asking me to not bring cakes due to self control issue. What should I do?

Is there a file that always exists and a 'normal' user can't lstat it?

Can the "Friends" spell be used without making the target hostile?

Not a Long-Winded Riddle

Eww, those bytes are gross

Why didn't Tom Riddle take the presence of Fawkes and the Sorting Hat as more of a threat?

How do I prevent a homebrew Grappling Hook feature from trivializing Tomb of Annihilation?

Translation needed for 130 years old church document

Is there a verb that means to inject with poison?

False written accusations not made public - is there law to cover this?



Why is the size of a directory either 0 or 4096? [duplicate]


What does size of a directory mean in output of 'ls -l' command?Why directory with large amounts of entries does not shrink in size after entries are removed?Why my partitions don't show the right capacity on a 4096 byte physical block hard drive?Why could the size of the “dot” file “.” exceed 4096?Why is this empty directory 3.5MB?Why the size of an empty directory in Linux is 4KB?How to update directory size after file removal?why Inode file size is different than actual sizeIs the slash (/) part of the name of the Linux root directory?ext4 or NTFS lost all files of the last 2 years. How can I recover them?Why is the difference in file size and it's size on disk bigger than 4 KiB?Why directory with large amounts of entries does not shrink in size after entries are removed?













4
















This question already has an answer here:




  • What does size of a directory mean in output of 'ls -l' command?

    4 answers




$ 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?










share|improve this question















marked as duplicate by Olorin, Michael Homer, Jeff Schaller, Stephen Harris, Gilles filesystems
Users with the  filesystems badge can single-handedly close filesystems questions as duplicates and reopen them as needed.

StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
1 hour ago


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • 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.

    – 炸鱼薯条德里克
    7 hours ago






  • 3





    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
    7 hours ago
















4
















This question already has an answer here:




  • What does size of a directory mean in output of 'ls -l' command?

    4 answers




$ 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?










share|improve this question















marked as duplicate by Olorin, Michael Homer, Jeff Schaller, Stephen Harris, Gilles filesystems
Users with the  filesystems badge can single-handedly close filesystems questions as duplicates and reopen them as needed.

StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
1 hour ago


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • 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.

    – 炸鱼薯条德里克
    7 hours ago






  • 3





    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
    7 hours ago














4












4








4


2







This question already has an answer here:




  • What does size of a directory mean in output of 'ls -l' command?

    4 answers




$ 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?










share|improve this question

















This question already has an answer here:




  • What does size of a directory mean in output of 'ls -l' command?

    4 answers




$ 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?





This question already has an answer here:




  • What does size of a directory mean in output of 'ls -l' command?

    4 answers








filesystems directory ext4 ntfs






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 7 hours ago







Tim

















asked 8 hours ago









TimTim

27.3k78264473




27.3k78264473




marked as duplicate by Olorin, Michael Homer, Jeff Schaller, Stephen Harris, Gilles filesystems
Users with the  filesystems badge can single-handedly close filesystems questions as duplicates and reopen them as needed.

StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
1 hour ago


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.









marked as duplicate by Olorin, Michael Homer, Jeff Schaller, Stephen Harris, Gilles filesystems
Users with the  filesystems badge can single-handedly close filesystems questions as duplicates and reopen them as needed.

StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
1 hour ago


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.










  • 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.

    – 炸鱼薯条德里克
    7 hours ago






  • 3





    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
    7 hours ago














  • 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.

    – 炸鱼薯条德里克
    7 hours ago






  • 3





    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
    7 hours 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.

– 炸鱼薯条德里克
7 hours 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.

– 炸鱼薯条德里克
7 hours ago




3




3





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
7 hours 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
7 hours ago










2 Answers
2






active

oldest

votes


















6














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






share|improve this answer

































    3














    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





    share|improve this answer





















    • 2





      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
      7 hours ago











    • I think most non-directory is also reported as size 0 on procfs or sysfs.

      – 炸鱼薯条德里克
      7 hours 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
      7 hours ago











    • @炸鱼薯条德里克 Yes, that's correct. Because that data literally occupies 0 blocks of disk space.

      – Sergiy Kolodyazhnyy
      7 hours ago








    • 1





      @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
      7 hours ago


















    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    6














    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






    share|improve this answer






























      6














      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






      share|improve this answer




























        6












        6








        6







        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






        share|improve this answer















        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







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 7 hours ago

























        answered 7 hours ago









        Ed GrimmEd Grimm

        4587




        4587

























            3














            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





            share|improve this answer





















            • 2





              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
              7 hours ago











            • I think most non-directory is also reported as size 0 on procfs or sysfs.

              – 炸鱼薯条德里克
              7 hours 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
              7 hours ago











            • @炸鱼薯条德里克 Yes, that's correct. Because that data literally occupies 0 blocks of disk space.

              – Sergiy Kolodyazhnyy
              7 hours ago








            • 1





              @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
              7 hours ago
















            3














            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





            share|improve this answer





















            • 2





              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
              7 hours ago











            • I think most non-directory is also reported as size 0 on procfs or sysfs.

              – 炸鱼薯条德里克
              7 hours 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
              7 hours ago











            • @炸鱼薯条德里克 Yes, that's correct. Because that data literally occupies 0 blocks of disk space.

              – Sergiy Kolodyazhnyy
              7 hours ago








            • 1





              @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
              7 hours ago














            3












            3








            3







            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





            share|improve this answer















            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






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited 6 hours ago

























            answered 7 hours ago









            Sergiy KolodyazhnyySergiy Kolodyazhnyy

            10.4k42663




            10.4k42663








            • 2





              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
              7 hours ago











            • I think most non-directory is also reported as size 0 on procfs or sysfs.

              – 炸鱼薯条德里克
              7 hours 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
              7 hours ago











            • @炸鱼薯条德里克 Yes, that's correct. Because that data literally occupies 0 blocks of disk space.

              – Sergiy Kolodyazhnyy
              7 hours ago








            • 1





              @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
              7 hours ago














            • 2





              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
              7 hours ago











            • I think most non-directory is also reported as size 0 on procfs or sysfs.

              – 炸鱼薯条德里克
              7 hours 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
              7 hours ago











            • @炸鱼薯条德里克 Yes, that's correct. Because that data literally occupies 0 blocks of disk space.

              – Sergiy Kolodyazhnyy
              7 hours ago








            • 1





              @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
              7 hours ago








            2




            2





            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
            7 hours 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
            7 hours ago













            I think most non-directory is also reported as size 0 on procfs or sysfs.

            – 炸鱼薯条德里克
            7 hours ago





            I think most non-directory is also reported as size 0 on procfs or sysfs.

            – 炸鱼薯条德里克
            7 hours 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
            7 hours 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
            7 hours ago













            @炸鱼薯条德里克 Yes, that's correct. Because that data literally occupies 0 blocks of disk space.

            – Sergiy Kolodyazhnyy
            7 hours ago







            @炸鱼薯条德里克 Yes, that's correct. Because that data literally occupies 0 blocks of disk space.

            – Sergiy Kolodyazhnyy
            7 hours ago






            1




            1





            @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
            7 hours 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
            7 hours ago



            Popular posts from this blog

            迭戈·戈丁...

            A phrase ”follow into" in a context The 2019 Stack Overflow Developer Survey Results Are...

            1960s short story making fun of James Bond-style spy fiction The 2019 Stack Overflow Developer...