Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Strange\s+fragmentation\s+in\s+nearly\s+empty\s+filesystem\s*$/: 14 ]

Total 14 documents matching your query.

1. Strange fragmentation in nearly empty filesystem (score: 1)
Author: Carsten Oberscheid <oberscheid@xxxxxxxxxxxx>
Date: Fri, 23 Jan 2009 11:21:30 +0100
Hi there, I am experiencing my XFS filesystem degrading over time in quite a strange and annoying way. Googling "XFS fragmenation" tells me either that this does not happen or to use xfs_fsr, which d
/archives/xfs/2009-01/msg01073.html (9,976 bytes)

2. Re: Strange fragmentation in nearly empty filesystem (score: 1)
Author: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Fri, 23 Jan 2009 09:25:27 -0600
I would suggest using xfs_bmap to look at the file layout, it will be much more informative than filefrag. I don't know how vmware is writing the files out (I don't use vmware, so can't test) but I'd
/archives/xfs/2009-01/msg01074.html (8,057 bytes)

3. Re: Strange fragmentation in nearly empty filesystem (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 24 Jan 2009 11:33:29 +1100
Oh, that's vmware being incredibly stupid about how they write out the memory images. They only write pages that are allocated and it's sparse file full of holes. Effectively this guarantees file fra
/archives/xfs/2009-01/msg01077.html (9,616 bytes)

4. Re: Strange fragmentation in nearly empty filesystem (score: 1)
Author: Carsten Oberscheid <oberscheid@xxxxxxxxxxxx>
Date: Mon, 26 Jan 2009 08:57:24 +0100
Well, things look a bit different over here: [co@tangchai]~/vmware/foo ls -la *.vmem -rw-- 1 co co 536870912 2009-01-23 10:42 foo.vmem [co@tangchai]~/vmware/foo xfs_bmap -vvp voo.vmem | grep hole | w
/archives/xfs/2009-01/msg01142.html (10,154 bytes)

5. Re: Strange fragmentation in nearly empty filesystem (score: 1)
Author: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Mon, 26 Jan 2009 12:37:01 -0600
It could still be being written backwards & synchronously, or some other way which doesn't play well with the allocator in xfs.... ok, so now it's reasonably rearranged; if you had 38 holes that mean
/archives/xfs/2009-01/msg01144.html (12,818 bytes)

6. Re: Strange fragmentation in nearly empty filesystem (score: 1)
Author: Carsten Oberscheid <oberscheid@xxxxxxxxxxxx>
Date: Tue, 27 Jan 2009 08:10:23 +0100
Point taken. Indeed. Unfortunately, since this is my office desktop PC, I'm quite reluctant to fiddle around with it too much. But perhaps I find an older live CD to try this with. Sounds perfectly r
/archives/xfs/2009-01/msg01159.html (9,362 bytes)

7. Re: Strange fragmentation in nearly empty filesystem (score: 1)
Author: Carsten Oberscheid <oberscheid@xxxxxxxxxxxx>
Date: Tue, 27 Jan 2009 09:40:34 +0100
Just booted an Ubuntu live CD from October 2007 and mounted the filesystem in question. Could not run vmware from there easily, so I tried just a copy of the vmem file: root@ubuntu# uname -a Linux ta
/archives/xfs/2009-01/msg01162.html (10,899 bytes)

8. Re: Strange fragmentation in nearly empty filesystem (score: 1)
Author: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 27 Jan 2009 10:30:38 +0100
What if you dd if=foo.vmem of=test bs=1000 ? That would do nearly the same as your "create empty file" test. mfg zmi -- // Michael Monnerie, Ing.BSc -- http://it-management.at // Tel: 0660 / 415 65 3
/archives/xfs/2009-01/msg01164.html (9,305 bytes)

9. Re: Strange fragmentation in nearly empty filesystem (score: 1)
Author: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Tue, 27 Jan 2009 07:30:32 -0600
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. You went from a
/archives/xfs/2009-01/msg01166.html (12,976 bytes)

10. Re: Strange fragmentation in nearly empty filesystem (score: 1)
Author: Carsten Oberscheid <oberscheid@xxxxxxxxxxxx>
Date: Tue, 27 Jan 2009 15:39:26 +0100
[co@tangchai]~/vmware/foo dd if=foo.vmem of=test_dd bs=1000 536870+1 Datensätze ein 536870+1 Datensätze aus 536870912 Bytes (537 MB) kopiert, 3,76026 s, 143 MB/s [co@tangchai]~/vmware/foo xfs_bmap -v
/archives/xfs/2009-01/msg01168.html (9,710 bytes)

11. Re: Strange fragmentation in nearly empty filesystem (score: 1)
Author: Carsten Oberscheid <oberscheid@xxxxxxxxxxxx>
Date: Tue, 27 Jan 2009 15:37:24 +0100
If this really is just a vmware and/or kernel problem that has nothing to do with the filesystem, then I agree. Yep. ... Didn't know this one. [co@tangchai]~/vmware/foo cp --sparse=never foo.vmem tes
/archives/xfs/2009-01/msg01169.html (11,723 bytes)

12. Re: Strange fragmentation in nearly empty filesystem (score: 1)
Author: Felix Blyakher <felixb@xxxxxxx>
Date: Tue, 27 Jan 2009 09:41:25 -0600
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? Not much could be tuned
/archives/xfs/2009-01/msg01170.html (10,476 bytes)

13. Re: Strange fragmentation in nearly empty filesystem (score: 1)
Author: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Tue, 27 Jan 2009 11:26:54 -0600
well when I say "kernel" I include the filesystem in that kernel. :) \o/ :) There is an -o allocsize=<number> which controls how much is speculatively allocated off the end of a file; in some cases i
/archives/xfs/2009-01/msg01172.html (12,193 bytes)

14. Re: Strange fragmentation in nearly empty filesystem (score: 1)
Author: Felix Blyakher <felixb@xxxxxxx>
Date: Tue, 27 Jan 2009 11:42:11 -0600
There is an -o allocsize=<number> which controls how much is speculatively allocated off the end of a file; in some cases it could help but I'm not sure it would in this case. "the end of a file" is
/archives/xfs/2009-01/msg01175.html (10,014 bytes)


This search system is powered by Namazu