On 2012-10-24 21:13, Chris Murphy wrote: > > On Oct 24, 2012, at 12:06 PM, Goffredo Baroncelli > <kreij...@gmail.com> wrote: >>> >> >> I was able to reproduce it: >> >> - I filled the filesystem until I got "No space left on device". > > I didn't even need to get that far. > > >> So it seems that I spread all the data to the other disk, filling >> up the smaller ones. So it stuck to "No space left on device". >> >> Now I rebalanced with -dconvert=single, as suggested by Hugo, then >> I was able to remove the disk: >> >> Label: 'test2' uuid: 11d0f1a8-2770-4ff2-8df5-f772f1056edc Total >> devices 3 FS bytes used 7.63GB devid 4 size 12.00GB used 9.48GB >> path /dev/vdf devid 3 size 3.00GB used 492.94MB path /dev/vdd >> devid 2 size 3.00GB used 64.00MB path /dev/vdc > > It's an interesting solution, but difficult for a larger file system. > Or at least, could be very time consuming. It is not a solution but a workaround.
> Aside from the "no space left" problem, the 'device delete' behavior > itself has kindof a high penalty: a successful 'device delete' on a > five disk raid10 (one was added in advance of the delete), all disks > are significantly written to, not merely a reconstruction of the > replaced disk. It means a lot of writing to do disk removals in the > face of an impending disk failure. I am not telling that this is the right solution, I am telling that this is the only solution available now :-( However this page https://btrfs.wiki.kernel.org/index.php/Project_ideas#Drive_swapping states that someone is working on this kind of issue. G.Baroncelli > > > Chris Murphy > > -- 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 > -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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
