From: "Pádraig Brady" <P@draigBrady.com>
To: xfs-oss <xfs@oss.sgi.com>
Cc: "Ondřej Vašík" <ovasik@redhat.com>
Subject: Strange hole creation behavior
Date: Fri, 11 Apr 2014 18:13:59 +0100 [thread overview]
Message-ID: <534822D7.7090803@draigBrady.com> (raw)
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
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2014-04-11 17:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-11 17:13 Pádraig Brady [this message]
2014-04-11 20:43 ` Strange hole creation behavior Brian Foster
2014-04-11 22:58 ` Pádraig Brady
2014-04-11 23:05 ` Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=534822D7.7090803@draigBrady.com \
--to=p@draigbrady.com \
--cc=ovasik@redhat.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).