On Wed, Dec 10, 2014 at 04:15:17PM -0600, sys.syphus wrote: > I am working on a script that i can run daily that will do maintenance > on my btrfs mountpoints. is there any reason not to concurrently do > all of the above? possibly including discards as well. > > > also, is there anything existing currently that will do maintenance on > btrfs so i don't have to reinvent the wheel? There's not a lot of wheel to reinvent. Just a one-liner in a crontab is sufficient. > #!/bin/bash > btrfs filesystem defragment -r -v /media/btrfs/ & > btrfs scrub start /media/btrfs/ & > btrfs balance start /media/btrfs/ & They should be run sequentially for simple performance reasons. They all attempt to occupy all the available disk bandwidth, so running them all at the same time just increases access latency and usually makes them much slower than if they were run sequentially. There is no cooperative scheduling of these operations in btrfs, even though they theoretically could be combined into a single pass. Run scrub once a week on low-end consumer drives, once a month on drives designed for NAS applications. Scrub is a fast and (assuming no errors are detected) read-only scan of allocated data areas that is well worth its relatively low cost. There's no need to run it daily--but there's no reason _not_ to run it daily either, if your disks' speed-to-size ratio is big enough. Don't run defragment at all, unless you have a database or VM image, and if you do, run defrag only on that. It's necessary for databases because each fragment ends up being the size of a database page, and the extent records for large badly-fragmented files consume almost as much RAM as the file pages themselves. defrag on arbitrary large files is a fairly good way to lock yourself out of your system: defrag will eventually finish, but in pathological cases it can take hours and prevent you from using the filesystem while it runs. You can try using the autodefrag mount option instead, but be prepared to turn it off if autodefrag is not right for your workload. Balance is something to use only when there is a configuration change (e.g. you added a new disk or replaced one with a larger one) or you've drastically changed the average size of files in a nearly-full filesystem. It will make the filesystem painfully slow the whole time it runs, and it can run for weeks on a filesystem smaller than 1TB. There's a _reason_ why balance requests persist across reboots. Speaking of reboots: if a balance is interrupted by a reboot, it can delay the next mount for minutes or hours (the mount command seems to hang until it has processed the interrupted block group) depending on filesystem size. > watch -d -n 30 "btrfs balance status /media/btrfs/; btrfs scrub status > /media/btrfs/" That part is fine. I throw in 'btrfs fi df' into the watches too.
Attachment:
signature.asc
Description: Digital signature
