On Tue, Apr 12, 2011 at 5:48 PM, Jan Kara <jack@xxxxxxx> wrote: > Hi, > > On Mon 11-04-11 16:37:57, Amir Goldstein wrote: >> Do you have an uptodate version of your recursive mtime patches? >> The only version I can find online is the original series from 2007. > I've put latest version (against 2.6.37) to > http://beta.suse.com/private/jack/recursive_mtime/ > Thanks, I'll see if we can use it for our application. >> I am interested in the patches for indexdb-like application, >> so persistence after crash is also important for my use case. >> Your patches would require the application to perform a full >> directory scan after crash, right? > OK, it depends. Currently, even mtime updates are not reliable (data can > be written to a file while mtime update is not yet committed). Recursive Yes, good point. > 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? 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. > 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
