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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
I have the same problem too, in general file deletion is very slow on btrfs (at least for me). On 11/7/2010 5:59 μμ, Lubos Kolouch wrote:> 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 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jul 12, 2010 at 10:30:20PM +0200, Clemens Eisserer spake thusly:> 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. -- Tracy Reed http://tracyreed.org
On Sun, Jul 11, 2010 at 02:59:12PM +0000, Lubos Kolouch wrote:> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Clemens Eisserer wrote (ao):> 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 -- Humilis IT Services and Solutions http://www.humilis.net -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html