[opensuse] XFS Slow When Deleting Large Files

older
[opensuse] vlc dependencies in -x64

Randall R Schulz

9 Mar 2009 9 Mar '09

14:34

Hi, Question first (background below): Why does XFS write every sector (formerly) occupied by a file when that file is deleted? If this is some sort of security feature, can it be disabled? This action makes deletion of large files very slow. Background: For a long time I noticed that there's a long period of disk-level write activity every time I shut down a VMware virtual machine. I always assumed this was some VMware-specific action taken as a part of shutting down a VM. Since I don't save the VM state in any way (either at the VMware level or by hibernating the Windows XP that I run in that VM), I was always annoyed and perplexed by this phenomenon. Based on the depiction of this activity in GKrellM, the amount of data written was about the same size as the virtual machine's RAM allocation. Today I was cleaning up some cache and index files from the previous version of my Java IDE (IDEA) and one of these files occupied about 1.25 GB. When I deleted it, I noticed the exact same pattern of disk-level I/O (and the "rm" invocation did not return until that I/O completed, just as VMware waits during its counterpart to this phenomenon) and it suddenly occurred to me what I saw when VMware shuts down was not it explicitly writing anything, but rather a large file being deleted (I still don' know why VMware needs a file to back RAM, but perhaps it does some kind of virtual memory thing of its own). So, to recapitulate the question: Why is XFS writing every sector (formerly) occupied by a file when it is deleted? Can it be prevented? Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Show replies by date

Ciro Iriarte

9 Mar 9 Mar

14:57

2009/3/9 Randall R Schulz :

...

Hi,

Question first (background below): Why does XFS write every sector (formerly) occupied by a file when that file is deleted? If this is some sort of security feature, can it be disabled? This action makes deletion of large files very slow.

Background:

For a long time I noticed that there's a long period of disk-level write activity every time I shut down a VMware virtual machine. I always assumed this was some VMware-specific action taken as a part of shutting down a VM. Since I don't save the VM state in any way (either at the VMware level or by hibernating the Windows XP that I run in that VM), I was always annoyed and perplexed by this phenomenon. Based on the depiction of this activity in GKrellM, the amount of data written was about the same size as the virtual machine's RAM allocation.

Today I was cleaning up some cache and index files from the previous version of my Java IDE (IDEA) and one of these files occupied about 1.25 GB. When I deleted it, I noticed the exact same pattern of disk-level I/O (and the "rm" invocation did not return until that I/O completed, just as VMware waits during its counterpart to this phenomenon) and it suddenly occurred to me what I saw when VMware shuts down was not it explicitly writing anything, but rather a large file being deleted (I still don' know why VMware needs a file to back RAM, but perhaps it does some kind of virtual memory thing of its own).

So, to recapitulate the question: Why is XFS writing every sector (formerly) occupied by a file when it is deleted? Can it be prevented?

Randall Schulz

Try mounting the FS with the "nobarrier" option... Ref: http://xfs.org/index.php/XFS_FAQ#Write_barrier_support. Regards, -- Ciro Iriarte http://cyruspy.wordpress.com -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Randall R Schulz

15:05

On Monday March 9 2009, Ciro Iriarte wrote:

...

2009/3/9 Randall R Schulz :

...
Hi,

Question first (background below): Why does XFS write every sector (formerly) occupied by a file when that file is deleted? If this is some sort of security feature, can it be disabled? This action makes deletion of large files very slow.

...

Randall Schulz

Try mounting the FS with the "nobarrier" option...

I'm pretty reluctant to do that. Power around here is flaky (at least by North American standards) and XFS doesn't handle power failures well as it is. Is that the only solution? Why didn't I see this in my 10.0 system? Did its version of XFS pre-date the addition of write barriers?

...

Ref: http://xfs.org/index.php/XFS_FAQ#Write_barrier_support.

... -- Ciro Iriarte

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R.

15:09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2009-03-09 at 07:34 -0700, Randall R Schulz wrote:

...

Question first (background below): Why does XFS write every sector (formerly) occupied by a file when that file is deleted? If this is some sort of security feature, can it be disabled? This action makes deletion of large files very slow.

Not in my system: 35000+0 records in 35000+0 records out 1146880000 bytes (1.1 GB) copied, 16.9719 s, 67.6 MB/s real 0m17.246s user 0m0.024s sys 0m4.500s cer@nimrodel:~/tmp> l -h bigfile - -rw-r--r-- 1 cer users 1.1G 2009-03-09 15:51 bigfile cer@nimrodel:~/tmp> time rm bigfile real 0m0.109s <================================= user 0m0.004s sys 0m0.056s cer@nimrodel:~/tmp> mount | grep /home /dev/hda11 on /home type xfs (rw,noatime,nodiratime) cer@nimrodel:~/tmp> cat /etc/SuSE-release openSUSE 11.0 (i586) VERSION = 11.0 cer@nimrodel:~/tmp> cat /proc/version Linux version 2.6.25.20-0.1-cer (geeko@buildhost) (gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux) ) #1 Wed Jan 28 19:02:29 CET 2009 nimrodel:~ # wrpm xfs_admin xfsprogs-2.9.8-7.1 XFS is the fastest filsystem deleting files. Maybe JFS is faster, they say (mythtv docs). - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm1MUsACgkQtTMYHG2NR9VSPwCfb9b/+H7J+MMFqpRmiIlsqKae BV0AoJiefWir0OhVGKa04Pa+PWUkz+W2 =1Zmf -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Randall R Schulz

15:25

On Monday March 9 2009, Carlos E. R. wrote:

...

On Monday, 2009-03-09 at 07:34 -0700, Randall R Schulz wrote:

...
Question first (background below): Why does XFS write every sector (formerly) occupied by a file when that file is deleted? If this is some sort of security feature, can it be disabled? This action makes deletion of large files very slow.

Not in my system:

I take it this was a dd command from /dev/zero to a file on an XFS file system?

...

35000+0 records in 35000+0 records out 1146880000 bytes (1.1 GB) copied, 16.9719 s, 67.6 MB/s

real 0m17.246s user 0m0.024s sys 0m4.500s

cer@nimrodel:~/tmp> l -h bigfile -rw-r--r-- 1 cer users 1.1G 2009-03-09 15:51 bigfile

cer@nimrodel:~/tmp> time rm bigfile

real 0m0.109s <================================= user 0m0.004s sys 0m0.056s

cer@nimrodel:~/tmp> mount | grep /home /dev/hda11 on /home type xfs (rw,noatime,nodiratime)

I don't suppress atime recording, though it's hard to see how that would relate to large-file deletion time.

...

...

XFS is the fastest filsystem deleting files. Maybe JFS is faster, they say (mythtv docs).

Since this came up, I've done some searching, and what I've found suggests that XFS has particularly _bad_ delete times. I found a page (http://everything2.com/index.pl?node_id=1479435, dated 2003) that details extensive tweaking meant to get XFS delete performance up. What size is your XFS log (journal) file? Mine seems small (its size was determined by the partitioning module of the openSUSE 11.1 installer). On my system, it is (use fixed-width font): % xfs_info /dev/sda5 meta-data=/dev/sda5 isize=256 agcount=4, agsize=1596458 blks = sectsz=512 attr=2 data = bsize=4096 blocks=6385829, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=3118, version=2 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 4096 * 3118 = 12.4 MiB

...

-- Cheers, Carlos Robinson

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Greg Freemyer

15:48

On Mon, Mar 9, 2009 at 10:25 AM, Randall R Schulz wrote:

...

On Monday March 9 2009, Carlos E. R. wrote:

...
On Monday, 2009-03-09 at 07:34 -0700, Randall R Schulz wrote:

...
Question first (background below): Why does XFS write every sector (formerly) occupied by a file when that file is deleted? If this is some sort of security feature, can it be disabled? This action makes deletion of large files very slow.

Not in my system:

I take it this was a dd command from /dev/zero to a file on an XFS file system?

...
35000+0 records in 35000+0 records out 1146880000 bytes (1.1 GB) copied, 16.9719 s, 67.6 MB/s

real 0m17.246s user 0m0.024s sys 0m4.500s

cer@nimrodel:~/tmp> l -h bigfile -rw-r--r-- 1 cer users 1.1G 2009-03-09 15:51 bigfile

cer@nimrodel:~/tmp> time rm bigfile

real 0m0.109s <================================= user 0m0.004s sys 0m0.056s

cer@nimrodel:~/tmp> mount | grep /home /dev/hda11 on /home type xfs (rw,noatime,nodiratime)

I don't suppress atime recording, though it's hard to see how that would relate to large-file deletion time.

...
...

XFS is the fastest filsystem deleting files. Maybe JFS is faster, they say (mythtv docs).

Since this came up, I've done some searching, and what I've found suggests that XFS has particularly _bad_ delete times. I found a page (http://everything2.com/index.pl?node_id=1479435, dated 2003) that details extensive tweaking meant to get XFS delete performance up.

xfs is notoriously slow at deleting small files. I tested deleting a linux kernel source tree a few weeks ago. I think reiser took a couple seconds. (I may have been testing ext3.) I know xfs took just over a minute. For large files, xfs is reputedly very fast. The dd test above, does not have any "sync" calls, so it may are may not mean anything. ie. The whole thing may have taken place in cache and not even caused any updates on disk. Who knows. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Randall R Schulz

15:56

On Monday March 9 2009, Greg Freemyer wrote:

...

On Mon, Mar 9, 2009 at 10:25 AM, Randall R Schulz wrote:

...
On Monday March 9 2009, Carlos E. R. wrote:

...
On Monday, 2009-03-09 at 07:34 -0700, Randall R Schulz wrote:

...
Question first (background below): Why does XFS write every sector (formerly) occupied by a file when that file is deleted? If this is some sort of security feature, can it be disabled? This action makes deletion of large files very slow.

...

xfs is notoriously slow at deleting small files. I tested deleting a linux kernel source tree a few weeks ago.

But I'm talking about it taking many, many seconds to delete a single large file.

...

I think reiser took a couple seconds. (I may have been testing ext3.)

I know xfs took just over a minute.

For large files, xfs is reputedly very fast.

Which I cannot square with what I'm seeing. The claims I see are that XFS has constant file deletion time w.r.t. the size of the file, but that is directly contradicted by my experience.

...

The dd test above, does not have any "sync" calls, so it may are may not mean anything.

You're not looking at the test that matters. I don't care how long it took to write the file, I'm dealing with the time taken to delete a large file. That and the fact that it's doing an amount of I/O (specifically, writes) that is directly proportional to the size of the file (in fact, it appears to be equal to the size of the file being deleted).

...

...

...

Greg

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R.

16:13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2009-03-09 at 08:56 -0700, Randall R Schulz wrote:

...

You're not looking at the test that matters. I don't care how long it took to write the file, I'm dealing with the time taken to delete a large file. That and the fact that it's doing an amount of I/O (specifically, writes) that is directly proportional to the size of the file (in fact, it appears to be equal to the size of the file being deleted).

Is your filesystem encripted, perhaps? Is it mounted "sync"? You are using 11.1, me 11.0, and I can't test today on 11.1 - but I can't believe there has been a regression there. I hope not! Was beagle indexing that file? Try creating a big file and removing it, while at runlevel 1, which means that nothing else will be running. Try running an "xfs_check" on that filesystem, find out if something is broken. I don't have more ideas... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm1QEEACgkQtTMYHG2NR9XW4QCdGdAM/4apFC8nLur3GeoIEkJt NtYAn1W5IjiABtj2igM7hl8m0MlZK7E2 =k0AC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Randall R Schulz

16:25

On Monday March 9 2009, Carlos E. R. wrote:

...

On Monday, 2009-03-09 at 08:56 -0700, Randall R Schulz wrote:

...
You're not looking at the test that matters. I don't care how long it took to write the file, I'm dealing with the time taken to delete a large file. That and the fact that it's doing an amount of I/O (specifically, writes) that is directly proportional to the size of the file (in fact, it appears to be equal to the size of the file being deleted).

Is your filesystem encripted, perhaps? Is it mounted "sync"?

Neither.

...

You are using 11.1, me 11.0, and I can't test today on 11.1 - but I can't believe there has been a regression there. I hope not!

Was beagle indexing that file?

Beagle has been expunged.

...

Try creating a big file and removing it, while at runlevel 1, which means that nothing else will be running.

Try running an "xfs_check" on that filesystem, find out if something is broken.

I don't have more ideas...

See my previous reply to your previous reply. The extent size on my system may be the culprit.

...

-- Cheers, Carlos E. R.

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R.

18:06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2009-03-09 at 09:25 -0700, Randall R Schulz wrote:

...

...
Try creating a big file and removing it, while at runlevel 1, which means that nothing else will be running.

Try running an "xfs_check" on that filesystem, find out if something is broken.

I don't have more ideas...

See my previous reply to your previous reply. The extent size on my system may be the culprit.

I just tested that on another of mine, and it is not... nimrodel:~ # xfs_info /dev/hdd8 meta-data=/dev/hdd8 isize=256 agcount=4, agsize=786681 blks = sectsz=512 attr=2 data = bsize=4096 blocks=3146724, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 log =internal bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 Created last December with 11.0, for you to compare. Try the rest of suggestion, runlevel, etc. You can also run the removal speed on different partitions of yours. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm1WsMACgkQtTMYHG2NR9U8HACggX/u8lOzrib1MOU7sqgkmXOZ LHIAn2Aiz6gAuVqCFaMxv82nxk/7CuEK =SA9N -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R.

16:01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2009-03-09 at 10:48 -0500, Greg Freemyer wrote:

...

The dd test above, does not have any "sync" calls, so it may are may not mean anything. ie. The whole thing may have taken place in cache and not even caused any updates on disk. Who knows.

No, because what I posted does not show is that I left the room after issuing the dd command and came back about 15 minutes later. I'm sure that the file is written by that time. Also, my RAM is 1GiB, so that file can not be cached. No, you can consider the file fully committed. As to XFS being reportedly slow at deleting files, my readings said the contrary, that it is very fast: go to the mythtv site and search the docs for the filesystems they have tried and which do they recommend. I can't give now an exact link. Maybe I'll try later creating and deleting a thousand small files. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm1PUIACgkQtTMYHG2NR9XQXgCeKtG97gYnKdJcbgEc/bIH6Xtn mZkAniS/KzQq5dtcpMojFVmL4wmIee77 =C+OB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Boris Epstein

16:06

On Mon, Mar 9, 2009 at 11:48 AM, Greg Freemyer wrote:

...

On Mon, Mar 9, 2009 at 10:25 AM, Randall R Schulz wrote:

...
On Monday March 9 2009, Carlos E. R. wrote:

...
On Monday, 2009-03-09 at 07:34 -0700, Randall R Schulz wrote:

...
Question first (background below): Why does XFS write every sector (formerly) occupied by a file when that file is deleted? If this is some sort of security feature, can it be disabled? This action makes deletion of large files very slow.

Not in my system:

I take it this was a dd command from /dev/zero to a file on an XFS file system?

...
35000+0 records in 35000+0 records out 1146880000 bytes (1.1 GB) copied, 16.9719 s, 67.6 MB/s

real 0m17.246s user 0m0.024s sys 0m4.500s

cer@nimrodel:~/tmp> l -h bigfile -rw-r--r-- 1 cer users 1.1G 2009-03-09 15:51 bigfile

cer@nimrodel:~/tmp> time rm bigfile

real 0m0.109s <================================= user 0m0.004s sys 0m0.056s

cer@nimrodel:~/tmp> mount | grep /home /dev/hda11 on /home type xfs (rw,noatime,nodiratime)

I don't suppress atime recording, though it's hard to see how that would relate to large-file deletion time.

...
...

XFS is the fastest filsystem deleting files. Maybe JFS is faster, they say (mythtv docs).

Since this came up, I've done some searching, and what I've found suggests that XFS has particularly _bad_ delete times. I found a page (http://everything2.com/index.pl?node_id=1479435, dated 2003) that details extensive tweaking meant to get XFS delete performance up.

xfs is notoriously slow at deleting small files. I tested deleting a linux kernel source tree a few weeks ago.

I think reiser took a couple seconds. (I may have been testing ext3.)

I know xfs took just over a minute.

For large files, xfs is reputedly very fast.

The dd test above, does not have any "sync" calls, so it may are may not mean anything. ie. The whole thing may have taken place in cache and not even caused any updates on disk. Who knows.

Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Sorry if this is off-topic but I am just wondering what is the special appeal of XFS? Is it the large-file capabilities? Or the alleged higher reliability/restorability in the event of a crash? Boris. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Lew Wolfgang

16:16

Boris Epstein wrote:

...

Sorry if this is off-topic but I am just wondering what is the special appeal of XFS? Is it the large-file capabilities? Or the alleged higher reliability/restorability in the event of a crash?

Hi Boris, This is unscientific because I didn't quantize my results, but I started using xfs because Reiserfs became unreliable in openSuSE 11.0. Back in the day I benchmarked Reiserfs vs ext3 and choose Reiserfs. Maybe ext4 will be better? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R.

16:07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2009-03-09 at 08:25 -0700, Randall R Schulz wrote:

...

I take it this was a dd command from /dev/zero to a file on an XFS file system?

Yes. Did I remove that line from the post? Oops! O:-)

...

...
cer@nimrodel:~/tmp> mount | grep /home /dev/hda11 on /home type xfs (rw,noatime,nodiratime)

I don't suppress atime recording, though it's hard to see how that would relate to large-file deletion time.

Me neither.

...

...
...

XFS is the fastest filsystem deleting files. Maybe JFS is faster, they say (mythtv docs).

Since this came up, I've done some searching, and what I've found suggests that XFS has particularly _bad_ delete times. I found a page (http://everything2.com/index.pl?node_id=1479435, dated 2003) that details extensive tweaking meant to get XFS delete performance up.

Funny. The mythtv people say otherwise, they tested filesystem for deletion speed, it affects their program.

...

What size is your XFS log (journal) file? Mine seems small (its size was determined by the partitioning module of the openSUSE 11.1 installer). On my system, it is (use fixed-width font):

% xfs_info /dev/sda5 meta-data=/dev/sda5 isize=256 agcount=4, agsize=1596458 blks = sectsz=512 attr=2 data = bsize=4096 blocks=6385829, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=3118, version=2 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0

4096 * 3118 = 12.4 MiB

Whatever the utility thought wise. Let me see: nimrodel:~ # xfs_info /dev/hda11 meta-data=/dev/hda11 isize=256 agcount=16, agsize=196670 blks = sectsz=512 attr=1 data = bsize=4096 blocks=3146720, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 log =internal bsize=4096 blocks=2560, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=65536 blocks=0, rtextents=0 So: 4096*2560 = 10 MiB. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm1PscACgkQtTMYHG2NR9UywwCeOozFmj7tFSBHSI/HimO/kBm5 4qkAn3u9qLr2zEAeLf+jlwY4uxVPomG+ =ALZL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Randall R Schulz

16:21

On Monday March 9 2009, Carlos E. R. wrote:

...

On Monday, 2009-03-09 at 08:25 -0700, Randall R Schulz wrote:

...
...

% xfs_info /dev/sda5 data = bsize=4096 ... realtime =none extsz=4096 blocks=0, rtextents=0

Whatever the utility thought wise. Let me see:

nimrodel:~ # xfs_info /dev/hda11 ... data = bsize=4096 ... ... realtime =none extsz=65536 blocks=0, rtextents=0

...

The most suspicious difference I see is that my file system was created with extents of the same size as its allocation units while yours are 64 KiB (both have allocation units of 4096 / 8 sectors). My reading on the Web suggests that with write barriers on (as they are for me now) that file deletion on XFS is proportional to the number of extents.

...

-- Cheers, Carlos Robinson

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Randall R Schulz

16:31

On Monday March 9 2009, Randall R Schulz wrote:

...

On Monday March 9 2009, Carlos E. R. wrote:

...
On Monday, 2009-03-09 at 08:25 -0700, Randall R Schulz wrote:

...
...

% xfs_info /dev/sda5 data = bsize=4096 ... realtime =none extsz=4096 blocks=0, rtextents=0

Whatever the utility thought wise. Let me see:

nimrodel:~ # xfs_info /dev/hda11 ... data = bsize=4096 ... ... realtime =none extsz=65536 blocks=0, rtextents=0

...

The most suspicious difference I see is that my file system was created with extents of the same size as its allocation units while yours are 64 KiB (both have allocation units of 4096 / 8 sectors). My reading on the Web suggests that with write barriers on (as they are for me now) that file deletion on XFS is proportional to the number of extents.

I looked at the extent size for all seven of my XFS file systems. The ones I carried over from my old SuSE Linux 10.0 installation all have extent size 64 KiB. The ones created during openSUSE 11.1 installation all have extent sizes 4 KiB (same as their allocation block size). J'accuse, openSUSE 11.1! But... What is the "real-time" aspect of this parameter? If "realtime=none" does the "extsz" reported matter? Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R.

18:04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: On Monday, 2009-03-09 at 09:31 -0700, Randall R Schulz wrote:

...

On Monday March 9 2009, Randall R Schulz wrote:

...
On Monday March 9 2009, Carlos E. R. wrote:

...

...
...
...
data = bsize=4096 ... realtime =none extsz=4096 blocks=0, rtextents=0

Whatever the utility thought wise. Let me see:

nimrodel:~ # xfs_info /dev/hda11 ... data = bsize=4096 ... ... realtime =none extsz=65536 blocks=0, rtextents=0

...

The most suspicious difference I see is that my file system was created with extents of the same size as its allocation units while yours are 64 KiB (both have allocation units of 4096 / 8 sectors). My reading on the Web suggests that with write barriers on (as they are for me now) that file deletion on XFS is proportional to the number of extents.

I think that it is related to the creation of large files, dunno about deletion.

...

I looked at the extent size for all seven of my XFS file systems. The ones I carried over from my old SuSE Linux 10.0 installation all have extent size 64 KiB. The ones created during openSUSE 11.1 installation all have extent sizes 4 KiB (same as their allocation block size).

J'accuse, openSUSE 11.1!

I have several sizes: nimrodel:~ # xfs_info /dev/hdd8 | grep extsz realtime =none extsz=4096 blocks=0, rtextents=0 nimrodel:~ # xfs_info /dev/hdd16 | grep extsz realtime =none extsz=65536 blocks=0, rtextents=0 nimrodel:~ # xfs_info /dev/hda11 | grep extsz realtime =none extsz=65536 blocks=0, rtextents=0 nimrodel:~ # xfs_info /dev/hda20 | grep extsz realtime =none extsz=65536 blocks=0, rtextents=0 nimrodel:~ # xfs_info /dev/mapper/cryptotab_loop0 | grep extsz realtime =none extsz=65536 blocks=0, rtextents=0 And: nimrodel:~ # mount | grep /dev/hdd8 /dev/hdd8 on /home1 type xfs I assure you I created it recently, under 11.0 - the date of the directory suggests last December.

...

But... What is the "real-time" aspect of this parameter? If "realtime=none" does the "extsz" reported matter?

All of mine have realtime none. Let me try the speed test on the one with the same extent size as yours. cer@nimrodel:/home1/cer/tmp> time dd if=/dev/zero of=bigfile bs=32K count=35000 ; time sync ; ls -lh bigfile 35000+0 records in 35000+0 records out 1146880000 bytes (1.1 GB) copied, 25.5806 s, 44.8 MB/s real 0m25.738s user 0m0.024s sys 0m4.708s real 0m1.331s user 0m0.000s sys 0m0.020s - -rw-r--r-- 1 cer users 1.1G 2009-03-09 18:51 bigfile cer@nimrodel:/home1/cer/tmp> time rm bigfile real 0m0.047s user 0m0.000s sys 0m0.008s The previous test was: real 0m17.246s user 0m0.024s sys 0m4.500s cer@nimrodel:~/tmp> time rm bigfile real 0m0.109s user 0m0.004s sys 0m0.056s So, creation is slower (I expected that), and removal was faster. Of course, I would have to run the test several times, but so far, no, that's not the reason. It may indeed be something in 11.1. I'll test that one of this days, but with the same filesystems, not a newly formatted one. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm1WiIACgkQtTMYHG2NR9XXcwCePWWnMLXec/es9tSh1JLiDvVp UQAAnj4KEnqubLVI6gtegcioOT10WZbB =YJW/ -----END PGP SIGNATURE-----

5560

Age (days ago)

5560

Last active (days ago)

List overview

Download

16 comments

7 participants

participants (7)

Boris Epstein
Carlos E. R.
Carlos E. R.
Ciro Iriarte
Greg Freemyer
Lew Wolfgang
Randall R Schulz

[opensuse] XFS Slow When Deleting Large Files

tags

participants (7)