On Tue, Jun 17, 2014 at 07:59:57AM -0700, Marc MERLIN wrote:
> It is also ok to answer "Any FS created or used before kernel 3.x can be
> corrupted due to bugs we fixed in 3.y, thank you for your report but it's
> not a good use of our time to investigate this"
> (although newer kernels should not just crash with BUG(xxx) on unexpected
> data, they should remount the FS read only).
I was thinking about this some more, and I know I have no right to tell
others what to do, so take this as a mere suggestion :)
How about doing a release with cleanups and stabilization and better state
reporting when things go wrong?
This would give a good known version for users who have actual data and
backups that can take many hours or days to restore (never mind downtime).
A few things I was thinking about:
1) Wouldn't it be a good time to replace all the BUG ON statements with
appropriate error handling? Unexpected data can happen, the kernel shouldn't
crash that.
At the very least it should remount read only and give maybe a wiki link to
the user on what to do next (some bu reporting and recovery page)
2) On unexpected cases, output basic information on the filesystem or printk
instructions to the user on how to gather data that would be sent to the
list to be reviewed.
This would include information on how old the filesystem is when it's
possible to detect, and the instruction page could say "sorry, anything
older than X, we don't want to hear about, we already fixed corruption bugs
since then"
3) getting printk data on an end user machine when it just started refusing
to write to disk can be challenging and cause useful debug info to be lost.
Things I thinking about:
a) make sure most btrfs bugs do not just hang the kernel
b) recommend to users to send kernel syslog messages to an ext4 partition
How does that sound?
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
--
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
