slow deletion of files
Hello,
during my testing of btrfs I found out,
that deletion of directory with many files (many millions) takes veeeery long (it is running two weeks now and did not finish).
But when instead of directory I create subvolume, it is deleted instantly.
Is it normal behaviour? (gentoo 2.6.34-r1, btrfs-progs-9999). Why the directory cannot be deleted instantly as well?
Thank you
Lubos
I have the same problem too, in general file deletion is very slow on=
=20
btrfs (at least for me).
Quoted 4 lines · Lubos Kolouch
Hello,
during my testing of btrfs I found out,
that deletion of directory with many files (many millions) takes veee=
ery
Quoted 3 lines
long (it is running two weeks now and did not finish).
But when instead of directory I create subvolume, it is deleted insta=
ntly.
Quoted 10 lines
Is it normal behaviour? (gentoo 2.6.34-r1, btrfs-progs-9999). Why the directory cannot be deleted instantly as well?
Thank you
Lubos
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs=
" in
Quoted 2 lines
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
Quoted 3 lines
Quoted 3 lines
during my testing of btrfs I found out,
that deletion of directory with many files (many millions) takes veeeery long (it is running two weeks now and did not finish).
Same for me. I moved back to ext4 on my backup-drive because deleting old backups created with BackInTime took forever to delete.
Another reason I moved away was btrfs corrupted, and btrfsck is still not able to repair it.
I really like btrfs but in my opinion it has still a long road to go and declaring it stable in 2.6.35 is quite optimistic at best.
- Clemens
Forgot to mention, I filed already a report for this problem:
https://bugzilla.kernel.org/show_bug.cgi?id=16117
However, like the other btrfs bug I filed, it was never looked at - so I decided it was a waste of time to file bugs against it.
- Clemens
On Mon, Jul 12, 2010 at 10:30:20PM +0200, Clemens Eisserer spake thusly:
Quoted 4 lines
Another reason I moved away was btrfs corrupted, and btrfsck is still not able to repair it.
I really like btrfs but in my opinion it has still a long road to go and declaring it stable in 2.6.35 is quite optimistic at best.
How many of reiserfs' problems were due to bugs in reiserfs vs due to buggy PC memory which is rarely ECC? These fancy new filesystems hold a lot of datastructures in memory compared to older filesystems which would seem to increase the chances that they could be broken by bad RAM. I am concerned that a flipped bit in memory somewhere could be written out to disk and hose the filesystem. I know ZFS implements a lot of checksums to prevent this sort of thing but it also tends to run on nicer hardware with ECC. I never had corruption problems with reiserfs even while running it on many terabytes of disk. I know plenty of people who constantly lost data to it. I can't explain the difference other than hardware.
Signature · 2 lines
Tracy Reed http://tracyreed.org
Clemens Eisserer wrote (ao):
Quoted 4 lines
Another reason I moved away was btrfs corrupted, and btrfsck is still not able to repair it.
I really like btrfs but in my opinion it has still a long road to go and declaring it stable in 2.6.35 is quite optimistic at best.
Please allow me to report in favor of btrfs.
I use btrfs since February 2009 on my workstation, since September 2009 on my home server, and since December 2009 on several ARM computers. Recently I've started to use btrfs on production servers.
Btrfs has not let me down yet. I do make hourly incremental backups and keep a close eye on the btrfs mailinglist though.
Sander
Signature · 2 lines
Humilis IT Services and Solutions http://www.humilis.net
Quoted 10 lines · Lubos Kolouch
Hello,
during my testing of btrfs I found out,
that deletion of directory with many files (many millions) takes veeeery long (it is running two weeks now and did not finish).But when instead of directory I create subvolume, it is deleted instantly.
Is it normal behaviour? (gentoo 2.6.34-r1, btrfs-progs-9999). Why the directory cannot be deleted instantly as well?
The subvolume deletion is able to walk much less metadata, and it is able to walk it in a more efficient order than a file by file deletion. Time to delete individual files depends mostly on metadata fragmentation and is mostly limited by reading in the file extent pointers and crcs.
The bulk of this work can be pushed into the background, it is definitely on my todo list.
-chris