From: Carsten Oberscheid <oberscheid@doctronic.de>
To: xfs@oss.sgi.com
Subject: Re: Strange fragmentation in nearly empty filesystem
Date: Tue, 27 Jan 2009 15:37:24 +0100 [thread overview]
Message-ID: <20090127143724.GP16931@doctronic.de> (raw)
In-Reply-To: <497F0C78.7060501@sandeen.net>
On Tue, Jan 27, 2009 at 07:30:32AM -0600, Eric Sandeen wrote:
> It'd be best to run vmware under some other kernel, and observe its
> behavior, not just mount some existing filesystem and look at existing
> files and do other non-vmware-related tests.
If this really is just a vmware and/or kernel problem that has nothing
to do with the filesystem, then I agree.
> You went from a file with 34 holes to one with 27k holes by copying it?
Yep.
> Perhaps this is cp's sparse file detection in action, seeking over
> swaths of zeros.
...
> Perhaps, if by "worse" you mean "leaves holes for regions with zeros".
> Try cp --sparse=never and see how that goes.
Didn't know this one.
[co@tangchai]~/vmware/foo cp --sparse=never foo.vmem test_nosparse
[co@tangchai]~/vmware/foo xfs_bmap -vvp test_ | grep hole | wc -l
test_livecd test_nosparse
[co@tangchai]~/vmware/foo xfs_bmap -vvp test_nosparse | grep hole | wc -l
0
[co@tangchai]~/vmware/foo xfs_bmap -vvp test_nosparse | grep -v hole | wc -l
9
You win.
> My best guess is that your cp test is making the file even more sparse
> by detecting blocks full of zeros and seeking over them, leaving more
> holes. Not really related to vmware behavior, though.
All right. So next I'll try and downgrade vmplayer.
Just out of couriosity (and stubbornness): Are there any XFS
parameters that might influence fragmentation for the better, in case
I have to put up with a stupid application?
Thanks for your time & thoughts & best regards
Carsten Oberscheid
--
carsten oberscheid d o c t r o n i c
email oberscheid@doctronic.de information publishing + retrieval
phone +49 228 92 682 00 http://www.doctronic.de
doctronic GmbH & Co. KG, Bonn
Handelsregister: HRA 4685 (AG Bonn); USt-ID: DE 210 898 186
Komplementärin: doctronic Verwaltungsges. mbH, Bonn, HRB 8926 (AG Bonn)
Geschäftsführer: Holger Flörke, Ingo Küper, Carsten Oberscheid
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-01-27 15:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-23 10:21 Strange fragmentation in nearly empty filesystem Carsten Oberscheid
2009-01-23 15:25 ` Eric Sandeen
2009-01-24 0:33 ` Dave Chinner
2009-01-26 7:57 ` Carsten Oberscheid
2009-01-26 18:37 ` Eric Sandeen
2009-01-27 7:10 ` Carsten Oberscheid
2009-01-27 8:40 ` Carsten Oberscheid
2009-01-27 9:30 ` Michael Monnerie
2009-01-27 14:39 ` Carsten Oberscheid
2009-01-27 13:30 ` Eric Sandeen
2009-01-27 14:37 ` Carsten Oberscheid [this message]
2009-01-27 15:41 ` Felix Blyakher
2009-01-27 17:26 ` Eric Sandeen
2009-01-27 17:42 ` Felix Blyakher
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=20090127143724.GP16931@doctronic.de \
--to=oberscheid@doctronic.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.