Re: kernel BUG at fs/btrfs/volumes.c:3753! These btrfs crashes at mount time on log replay are really a problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > The equivalent consistent update mechanism in btrfs is cow tree updates.
> > The superblock that references new tree blocks written to free space is
> > itself only written once all those blocks are stable on disk.  If the
> > tree block writes are interrupted then the superblock isn't updated and
> > btrfs won't see the partially written blocks.  No worries.
> 
> Ok. So basically what I seem to be hitting, are seemingly complete tree
> blocks in the log, that aren't complete or consistent afterall, triggering 
> BUG() in the end.

That's my understanding, yes.  I think Josef is digging in.

> I understand that this might not want to be a default, but it should be
> something that could be done from the kernel command line, and allow the
> mount to continue and the boot to succeed (including the kernel debug log to
> make it to local disk, where it can then be Emailed since serial console or
> netconsole is not something you can do easily)
> 
> Does that sound reasonable?

To me?  Absolutely.  Having to recover with btrfs-zero-log is annoying.
I'd be surprised if anyone didn't agree that the current process should
be improved.

- z
--
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


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux