| 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
| ||
|
Date: Tue, 19 May 2009 07:36:44 -0400 From: Theodore Tso <tytso@....edu> To: Thierry Vignaud <tvignaud@...driva.com> Cc: Kevin Shanahan <kmshanah@...b.org.au>, Andreas Dilger <adilger@....com>, Alex Tomas <bzzz@....com>, linux-ext4@...r.kernel.org Subject: Re: More ext4 acl/xattr corruption - 4th occurence now On Tue, May 19, 2009 at 12:00:56PM +0200, Thierry Vignaud wrote: > I wonder if that would explain the corruption I reported a couple weeks > ago. > > Now I remember I wrongly got 2 parallel cp from the same source > directory to the same target directory. > > Could this be the cause? Yes, it's possible. There could be a problem either if the two cp's tried targetting the same file at the same time, or if the directory was getting expanded at the same time by the two different processes. Since we don't cache logical->physical mapping for directories (since because of the journalling requirements directories are stored in the buffer cache, not the page cache), rather more likely to run into problems with directories; more so since directoris will tend to be fragmented. On the other hand, most of the time writes into the directory will tend to be into pre-existing free space; but if you had two parallel cp's copying a large number of files into the same directory, that could certainly happen. - Ted -- 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