On Thu, 2011-10-13 at 23:03 +0200, krz...@gmail.com wrote: > > > If you delete a large number of files, then there is no avoiding the > > fact that a lot of metadata needs to be updated. In this respect > btrfs > > is unlikely to be significantly faster than any other filing system. > > Are you sure? That would mean that instant deletion of subvolume in > btrfs is actualy taking ??SAME?? time and io power in BACKGROUND like > deleting by rm -rf in any filesystem. > Common misconception would be that subvolume deletion is much more > efficient and near zero time consuming. I think it is very important > to clear that up.
I may be wrong but it may not be necessary true - the fs may optimize
the deletion so for example if 2 files shares the same extend it is
updated once (it may be beneficial as cost of I/O is bigger then cost of
CPU).
Additionally it means that the btrfs does things asynchronously and we
don't need to wait for all cleanup (I assume that it is as soon as the
deletion is commited to log). Therefore if deletion takes 100 ms of i/o
and 10 ms of cpu on other fs and 100 ms of i/o and 20 ms of cpu on btrfs
the following code takes 210 ms vs. 120 ms on btrfs in very simplified
model.
unlink("/btrfs/file");
busy_wait(100); // Simulates 100 ms computation
Regards
PS. I'm not btrfs developer but I see at least potential advantages of
asynchronous deletion (or split deletion in 2-phases). I don't know how
much is implemented.
signature.asc
Description: This is a digitally signed message part
