[Top] [All Lists]

Files full of zeros with coreutils-8.11 and xfs (FIEMAP related?)

To: coreutils@xxxxxxx
Subject: Files full of zeros with coreutils-8.11 and xfs (FIEMAP related?)
From: Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx>
Date: Thu, 14 Apr 2011 12:26:08 +0200
Cc: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=simple; d=mail.ud10.udmedia.de; h= date:from:to:cc:subject:message-id:mime-version:content-type; q= dns/txt; s=beta; bh=4lcuYLRhXt6GAjm8upwOex2cpNFE5i0DD4Udb5Ruhgc=; b= YMZlV9V0P4WEqzmn/IsinaJLBpVmcoh1Xbxy63SS6DlBI31VNYXAbR5Bwdpr5dN8 r+Nwbd4iKwaqex1W6Hs2nbndDx6U/srC1nevvuE0u4Bsv6Ctx3hafSYEznMb1dFY BfLUgpGPRax33leifIqm8vJ+qtDE8wCfnEghNDSqYYo=
I trashed my system this morning when I installed coreutils-8.11.

What happened is that coreutils compiles and links correctly, but then
the following command (during the installation phase):

./ginstall chroot hostid nice who users pinky stty df stdbuf [ base64 basename 
cat chcon chgrp chmod chown cksum comm cp csplit cut date dd dir dircolors 
dirname du echo env expand expr factor false fmt fold head id join link ln 
logname ls md5sum mkdir mkfifo mknod mktemp mv nl nproc nohup od paste pathchk 
pr printenv printf ptx pwd readlink rm rmdir runcon seq sha1sum sha224sum 
sha256sum sha384sum sha512sum shred shuf sleep sort split stat sum sync tac 
tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq 
unlink vdir wc whoami yes arch 

apparently produces files which have the length of the originals but are
full of zeros. (and these were then installed to my live system, thereby
trashing it).

Now all the above is automated, because I use gentoo.
But when I run the command above (ginstall) later again by hand,
everything is copied just fine and the resulting binaries are all

The partition in question uses xfs.

# xfs_info /var
meta-data=/dev/sda1              isize=256    agcount=4, agsize=12800000 blks
         =                       sectsz=4096  attr=2
data     =                       bsize=4096   blocks=51200000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=25000, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

This is a 4kb hard drive (sectsz=4096).

I'm running the lastest vanilla git kernel (2.6.39-rc3-00087-gda768a4).

Now my question is, could this be caused by the recent FIEMAP changes in

<Prev in Thread] Current Thread [Next in Thread>