search for: bsddf

...3846656 >> which is 211480576 bytes smaller than what tune2fs tell me. > > By default, df on extN assumes that metadata used by the filesystem > was never available for your use and is not part of the filesystem > space. > > Documentation/filesystems/ext3.txt says: > > bsddf (*) Make 'df' act like BSD. > minixdf Make 'df' act like Minix. > > which is pretty unhelpful I suppose. ;) > > The mount man page is a little more helpful: > > bsddf|minixdf > Set the behaviour for the sta...

...1 on the same FS tell me the disk is 13243846656 > which is 211480576 bytes smaller than what tune2fs tell me. By default, df on extN assumes that metadata used by the filesystem was never available for your use and is not part of the filesystem space. Documentation/filesystems/ext3.txt says: bsddf (*) Make 'df' act like BSD. minixdf Make 'df' act like Minix. which is pretty unhelpful I suppose. ;) The mount man page is a little more helpful: bsddf|minixdf Set the behaviour for the statfs system call. The minixdf...

...576 bytes smaller than what tune2fs tell me. >> >> By default, df on extN assumes that metadata used by the filesystem >> was never available for your use and is not part of the filesystem >> space. >> >> Documentation/filesystems/ext3.txt says: >> >> bsddf (*) Make 'df' act like BSD. >> minixdf Make 'df' act like Minix. >> >> which is pretty unhelpful I suppose. ;) >> >> The mount man page is a little more helpful: >> >> bsddf|minixdf >>...

Hello guys, I have some difficulties to understand what really are the numbers behing "df" and tune2fs. You'll find the output of tune2fs and df below, on which my maths are based. Here are my maths: A tune2fs on an ext3 FS tell me the FS size is 3284992 block large. It also tell me that the size of one block is 4096 (bytes if I'm not wrong?). So my maths tell me that the disk

...2fs tell me. >>> >>> By default, df on extN assumes that metadata used by the filesystem >>> was never available for your use and is not part of the filesystem >>> space. >>> >>> Documentation/filesystems/ext3.txt says: >>> >>> bsddf (*) Make 'df' act like BSD. >>> minixdf Make 'df' act like Minix. >>> >>> which is pretty unhelpful I suppose. ;) >>> >>> The mount man page is a little more helpful: >>> >>> bsddf|m...

...t;>>> By default, df on extN assumes that metadata used by the filesystem >>>> was never available for your use and is not part of the filesystem >>>> space. >>>> >>>> Documentation/filesystems/ext3.txt says: >>>> >>>> bsddf (*) Make 'df' act like BSD. >>>> minixdf Make 'df' act like Minix. >>>> >>>> which is pretty unhelpful I suppose. ;) >>>> >>>> The mount man page is a little more helpful: >>>> &gt...

...ese 11,656,064 > blocks is that don't belong to an inode but are still marked as > used? At least some is filesystem metadata. mkfs.ext4 preallocates inode tables, bitmaps, etc, and that takes space from the filesystem. But that's not supposed to be shown by default, with the "bsddf" behavior that's hidden from the total available. >From above, 468346644*1024=479586963456; let's make a filesystem of the same size: # truncate --size=479586963456 fsfile # mkfs.ext4 fsfile # mount -o loop fsfile # df mnt/ Filesystem 1K-blocks Used Available Use%...

Hello everybody, first of all thank you the development of Ext2/3/4. It works like a charm and makes it possible to base applications on it. However, now I have the first time where I need more information to understand the behaviour of a ext4 installation on a 480 GB harddisk. It holds a database with a size of 355 GB, as said by "du -m": ... 355263 /opt/ssd However,

Can anyone tell me the history of CONFIG_EXT{2,3}_CHECK? There is code for a "check" option for mount if these options are enabled, but there's no way to enable them. TIA Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said.