| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20110412154830.GF5246@quack.suse.cz> Date: Tue, 12 Apr 2011 17:48:30 +0200 From: Jan Kara <jack@...e.cz> To: Amir Goldstein <amir73il@...il.com> Cc: Ext4 Developers List <linux-ext4@...r.kernel.org> Subject: Re: recursive mtime patches 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/ > 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 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. Honza -- Jan Kara <jack@...e.cz> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists