I think the i_version changes that hit mainline about a week ago are not as nice as they should be. First there's a complete lack of documentation on this, which is very bad. Please document what the new semantics for i_version on regular files are supposed to be, and how it differes from the existing semantics for directories. Second abusing one of the rather scare superblock mount flags is a bad idea. It would be much better to set this through ->setattr and an extension of struct iattr. ...

No, none of this is shared with e2fsprogs; e2fsprogs stopped using the There might be other programs like grub that may depend upon ext2_fs.h or ext3_fs.h.... <apt-get source / grep> Nope, not grub. So a few things might break, but they are all programs that should have been using the libraries shipped with e2fsprogs, and they wouldn't be Note Linus just accepted a pull from me (although it just missed the -git21 snapshot window --- <aside> it would be nice if that happend at 3...

Not sure what you are talking about. This seems very right to me. We want memory-low notification, not yet another generic communication mechanism. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -

Hi, With the patch below on top of yours, affs will survive a little longer. There were a few problems with recovering from allocation failures (and there are probably a few left). bye, Roman Index: linux/fs/affs/affs.h =================================================================== --- linux.orig/fs/affs/affs.h +++ linux/fs/affs/affs.h @@ -48,7 +48,7 @@ struct affs_ext_key { * affs fs inode data in memory */ struct affs_inode_info { - u32 i_opencnt; + atomic_t i_opencnt; ...