On 12/08/15 16:06, Marc MERLIN wrote: > Howdy, > > Why would scrub need space and why would it cancel if there isn't enough of > it? > (kernel 4.3) > > /etc/cron.daily/btrfs-scrub: > btrfs scrub start -Bd /dev/mapper/cryptroot > scrub device /dev/mapper/cryptroot (id 1) done > scrub started at Mon Dec 7 01:35:08 2015 and finished after 258 seconds > total bytes scrubbed: 130.84GiB with 0 errors > btrfs scrub start -Bd /dev/mapper/pool1 > ERROR: scrubbing /dev/mapper/pool1 failed for device id 1 (No space left on > device) > scrub device /dev/mapper/pool1 (id 1) canceled
Scrub rewrites metadata (apparently even in -r aka readonly mode), and that can lead to temporary metadata expansion (stuff gets COWed around); it's a bit surprising but makes sense if you think about it. The fact that you ENOSPCed means that the fs was probably already fully allocated. If it bothers you, a subsequent balance with -musage=10 should vacuum things up. Alternatively just keep using the filesystem; eventually the empty metadata chunks should be collected, on the next remount at the latest. tl;dr: Never allocate all the chunks. Yes, this needs more graceful handling. -h -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
