Thanks for the comments. We are in the midst of making defrag better. For now, -r option picks up files of the dir specified, there is no way to defrag all subvol tree with out scripting, something like this. If /mnt is mounted with subvolid=5 (default). for all s subvol in /mnt do btrfs fi defrag /mnt/$s done btrfs fi defrag /mnt btrfs fi defrag -vr /mnt (file defrag)
In my personal experience Btrfs filesystems tend to get slower over time, up to the point where it takes several minutes to mount them or to delete some big files (observed on HDDs, not on SSDs where the sheer speed might masks the problem and filesystem tends to be smaller anyway). When it gets really bad, Gentoo's localmount script starts to time out on boot and Samba based network file deletions tend to freeze the client Windows machine's file explorer. It only takes 3-6 months and/or roughly 10-20 times of the total disk(s) capacity's worth of write load to get there.
IMO. The solution has to be reviewed against the use case here, and certainly it takes a lot of time. In some cases the access pattern for write may be different from accessed for read-only. Need to understand the context in which the the access leads to the timeout. And then tuning might help.
Defrag doesn't seem to help with that but running a balance on each and every metadata blocks (data and system blocks can be skipped) seems to "renew" it (no more timeouts or noticeable delays on mount, metadata operation are as fast as expected, it works like a young filesystem...).
Whats the defrag command you found didn't help but the above balance command helped ? Thanks Anand -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
