search for: ext3_statfs

...*sb); -extern void ext3_put_super (struct super_block *); -extern void ext3_write_super (struct super_block *); -extern void ext3_write_super_lockfs (struct super_block *); -extern void ext3_unlockfs (struct super_block *); -extern int ext3_remount (struct super_block *, int *, char *); -extern int ext3_statfs (struct super_block *, struct kstatfs *); #define ext3_std_error(sb, errno) \ do { \ if ((errno)) \ __ext3_std_error((sb), __FUNCTION__, (errno)); \ } while (0) -extern const char *ext3_decode_error(struct super_block *sb, int errno, char nbuf[16]); /* * Inodes and fil...

Hello Andrew, I patched 2.4.20 with your patch found out on http://lwn.net/Articles/17447/ and I have a big problem with: once server is booted on 2.4.20 with your patch, when I want to reboot with /sbin/reboot, server makes a Segmentation fault and it crashs. I tested it on 50-60 servers and it is the same problem. I tested kernel 2.4.20 without your patch: no problem. # uname -a Linux XXXXXX

...de, /* BKL not held. We take it */ put_super: ext3_put_super, /* BKL held */ write_super: ext3_write_super, /* BKL held */ + sync_fs: ext3_sync_fs, write_super_lockfs: ext3_write_super_lockfs, /* BKL not held. Take it */ unlockfs: ext3_unlockfs, /* BKL not held. We take it */ statfs: ext3_statfs, /* BKL held */ @@ -1577,24 +1580,22 @@ int ext3_force_commit(struct super_block * This implicitly triggers the writebehind on sync(). */ -static int do_sync_supers = 0; -MODULE_PARM(do_sync_supers, "i"); -MODULE_PARM_DESC(do_sync_supers, "Write superblocks synchronously"...

In fact the thing I really want to achieve is to be able to find the values and the algorithm that enable me to reproduce the percentage given by df (and to understand deeply what it means). Why do I need it? Because I'm trying to write some script to do capacity planning and space problem forecast. Currently I don't really know which values I should use to do it. (I could use the

Hello, I just noticed that 'tune2fs -l' did not returned a "lively" updated information regarding the free inodes count (looks like it's always correct after unmounting). It became suprising after an online resizing operation, where the total inode count was immediatly updated (grown in my case) but the free inode count was the same: one could deduce that suddenly a lot of

OK. Thanks for the journal information. I thought tune2fs -l and dumpe2fs were the same. In reality it's almost the same but not entirely ^^ I hear you about all the internal mecanisms that make the FS working or give it some features, and I do understand that it takes some place on the disk. However what I don't understand is why the number given in the "available column" is