slow deletion of files

slow deletion of files

[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?

Thank you

Lubos

Re: slow deletion of files

[Konstantinos Skarlatos]

  I have the same problem too, in general file deletion is very slow on=
=20
btrfs (at least for me).

On 11/7/2010 5:59 =CE=BC=CE=BC, Lubos Kolouch wrote:
> Hello,
>
> during my testing of btrfs I found out,
> that deletion of directory with many files (many millions) takes veee=
ery
> long (it is running two weeks now and did not finish).
>
> But when instead of directory I create subvolume, it is deleted insta=
ntly.
>
> 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

Re: slow deletion of files

[Clemens Eisserer]

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

Re: slow deletion of files

[Clemens Eisserer]

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

Re: slow deletion of files

[Tracy Reed]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: slow deletion of files

[Chris Mason]

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

Re: slow deletion of files

[Sander]

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