On Wed 13-04-11 21:16:40, Amir Goldstein wrote: > On Tue, Apr 12, 2011 at 5:48 PM, Jan Kara <jack@xxxxxxx> wrote: > > modification stamps have possibly larger race windows but I haven't really > > tried how much (I just know that even mtime races are not that hard to > > trigger if you try). So it really depends on how big reliability do you > > expect and I personally don't find much value in just rescanning and > > checking for mtime after a crash. Reading all the data and doing checksum > > certainly has more value but at a high cost. > > > > What do you thing about the approach to store recursively modified dir inodes in > a journal "modified inode descriptor block" and update the recursive mtime of > those dirs on journal recovery? The trouble is you don't know the number of directories that may need to have timestamp updated - you find that out only as you travel upwards. So it's hard to reserve any fixed space for this. > I would also consider to use a mount option rec_mtime and then just > store recursive > mtime in the directory's inode mtime instead of an extended attribute. > That doesn't break any contract with user space, it's just a re-interpretation > of the dir modification notion. It breaks POSIX specification - POSIX pretty much specifies when mtime is supposed to be changed - so I'm not sure we really want to do that... Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
