| 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: <BANLkTikW72q_2pEoVTmag8+gMsCcZ-fR8w@mail.gmail.com> Date: Fri, 15 Apr 2011 00:04:09 +0800 From: Yongqiang Yang <xiaoqiangnk@...il.com> To: Eric Sandeen <sandeen@...deen.net> Cc: Pádraig Brady <P@...igbrady.com>, xfs-oss <xfs@....sgi.com>, linux-ext4@...r.kernel.org, coreutils@....org, Markus Trippelsdorf <markus@...ppelsdorf.de> Subject: Re: Files full of zeros with coreutils-8.11 and xfs (FIEMAP related?) 2011/4/14 Eric Sandeen <sandeen@...deen.net>: > On 4/14/11 10:52 AM, Pádraig Brady wrote: >> On 14/04/11 16:50, Eric Sandeen wrote: >>> On 4/14/11 9:59 AM, Pádraig Brady wrote: >>>> On 14/04/11 15:02, Markus Trippelsdorf wrote: >>>>>>> Hi Pádraig, >>>>>>> >>>>>>> here you go: >>>>>>> + filefrag -v unwritten.withdata >>>>>>> Filesystem type is: ef53 >>>>>>> File size of unwritten.withdata is 5120 (2 blocks, blocksize 4096) >>>>>>> ext logical physical expected length flags >>>>>>> 0 0 274432 2560 unwritten,eof >>>>>>> unwritten.withdata: 1 extent found >>>>>>> >>>>>>> Please notice that this also happens with ext4 on the same kernel. >>>>>>> Btrfs is fine. >>>>>> >>>>> `filefrag -vs` fixes the issue on both xfs and ext4. >>>> >>>> So in summary, currently on (2.6.39-rc3), the following >>>> will (usually?) report a single unwritten extent, >>>> on both ext4 and xfs >>>> >>>> fallocate -l 10MiB -n k >>>> dd count=10 if=/dev/urandom conv=notrunc iflag=fullblock of=k >>>> filefrag -v k # grep for an extent without unwritten || fail >>> >>> right, that's what I see too in testing. >>> >>> But would the coreutils install have done a preallocation of the destination file? >>> >>> Otherwise this looks like a different bug... >>> >>>> This particular issue has been discussed so far at: >>>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8411 >>>> Note there it was stated there that ext4 had this >>>> fixed as of 2.6.39-rc1, so maybe there is something lurking? >>> >>> ext4 got a fix, but not xfs, I guess. My poor brain can't remember, I think I started looking into it, but it's clearly still broken. >>> >>> Still, I don't know for sure what happened to Markus - did something preallocate, in his case? >> >> Well that preallocate test is failing for him >> when the source file is either on ext4 or xfs. >> He noticed the issue initially on XFS when copying >> none preallocated files, so XFS probably just has >> the general issue of needing a sync before fiemap, >> where as EXT4 just has this preallocate one >> (though I've not seen it myself). >> >> cheers, >> Pádraig. >> > > well, if I simply take the preallocation step out of the testcase, it works fine on xfs without a sync. > > So I still don't know what Markus hit... Sorry for that my patch ignored fallocate. The situation is like this: An user allocated space for a file with fallocate, and write a small part of it. and the written is not flushed. The extent stays one unwritten extent in disk and memory with delayed allocation. In ext4 ext4_ext_walk_space() thinks an extent does not exist only if there is no any extents on disk. So ext4_ext_walk_space() thinks there is a extent and ext4_ext_fiemap_cb() thus ignores pagecache. I think ext4_ext_walk_space() should take unwritten extent not exist. Yongqiang. > > -Eric > -- > 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 > -- Best Wishes Yongqiang Yang -- 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