xfs
[Top] [All Lists]

Strange hole creation behavior

To: xfs-oss <xfs@xxxxxxxxxxx>
Subject: Strange hole creation behavior
From: PÃdraig Brady <P@xxxxxxxxxxxxxx>
Date: Fri, 11 Apr 2014 18:13:59 +0100
Cc: OndÅej VaÅÃk <ovasik@xxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2
So this coreutils test is failing on XFS:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=tests/dd/sparse.sh;h=06efc7017
Specifically the last hole check on line 66.

In summary what's happening is that a write(1MiB), lseek(1MiB), write(1MiB)
creates only a 64KiB hole. Is that expected?

Now a 1MiB hole is supported using truncate:
  dd if=/dev/urandom of=file.in bs=1M count=1 iflag=fullblock
  truncate -s+1M file.in
  dd if=/dev/urandom of=file.in bs=1M count=1 iflag=fullblock conv=notrunc 
oflag=append
  $ du -k file.in
  2048  file.in

But when trying to create the 1MiB hole with dd (lseek) it fails?

  # Create 3MiB input file file
  $ dd if=/dev/urandom of=file.in bs=1M count=3 iflag=fullblock
  $ dd if=/dev/zero    of=file.in bs=1M count=1 seek=1 conv=notrunc
  $ du -k file.in
  3072  file.in

  # Convert to 1MiB hole doesn't work :(
  $ dd if=file.in of=file.out bs=1M conv=sparse
  $ du -k file.out
  3008  file.out

  # Again with syscall details:
  $ strace -e write,lseek dd if=file.in of=file.out bs=1M conv=sparse
  write(1, "...", 1048576) = 1048576
  lseek(1, 1048576, SEEK_CUR)             = 2097152
  write(1, "...", 1048576) = 1048576

So it seems that the lseeks are treated differently to the truncate
that was done in the first example, which is surprising.
If we look at the file layout we can see the hole is
only at the last 64KiB of the middle 1MiB of zeros,
rather than for the whole middle 1MiB as in the first example??

  $ filefrag -v file.out
  Filesystem type is: 58465342
  File size of file.out is 3145728 (768 blocks of 4096 bytes)
   ext:     logical_offset:        physical_offset: length:   expected: flags:
     0:        0..     495:      31271..     31766:    496:
     1:      512..     767:      31783..     32038:    256:      31767: eof

thanks,
PÃdraig.

Versions etc. in case useful

$ uname -a
Linux tp2 3.12.6-300.fc20.x86_64 #1 SMP Mon Dec 23 16:44:31 UTC 2013 x86_64 
x86_64 x86_64 GNU/Linux

$ xfs_info .
meta-data=/dev/loop2             isize=256    agcount=4, agsize=65536 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

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