On Sun, Feb 2, 2020 at 6:29 AM Stephan von Krawczynski <skraw.ml@xxxxxxxxxx> wrote: > > On Sun, 2 Feb 2020 20:56:20 +0800 > Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > > > On 2020/2/2 下午8:45, Skibbi wrote: > > > Hello, > > > So I decided to try btrfs on my new portable WD Password Drive > > > attached to Raspberry Pi 4. I created GPT partition, created luks2 > > > volume and formatted it with btrfs. Then I created 3 subvolumes and > > > started copying data from other disks to one of the subvolumes. After > > > writing around 40GB of data my filesystem crashed. That was super fast > > > and totally discouraged me from next attempts to use btrfs :( > > > But I would like to help with development so before I reformat my > > > drive I can help you identifying potential issues with this filesystem > > > by providing some debugging info. > > > > > > Here are some details: > > > > > > root@rpi4b:~# uname -a > > > Linux rpi4b 4.19.93-v7l+ #1290 SMP Fri Jan 10 16:45:11 GMT 2020 armv7l > > > GNU/Linux > > > > Pretty old kernel, nor recently enough backports. > > Exactly this kind of answer made me leave btrfs and never come back again. > 4.19.93 is not very far away from the _latest_ longterm kernel released (which > is 4.19.101). > What you are saying here is that there is no stable working btrfs in longterm > kernels at all. No, Qu means there's not enough tree checking information to do anything other than speculate what the problem is. There's a lot more information provided by recent kernels about fs corruption causes, and that's just not going to be backported, it's too much work. > Hear, hear. > My advice to the OP: use ZFS. Great performance, absolutely stable, no crash > in years. Based on the available information, it would probably spectacularly fail too because of underlying storage betrayal. And if those kernel messages were likewise filtered, it'd suggests ZFS confusion. Unsurprising. ZFS doesn't let you magically use a failing storage stack. -- Chris Murphy
