[Bug 265951] ext2fs: kernel panic when trivial rsync operation from zfs to ext3 partitions

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265951

Warner Losh <imp@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |imp@FreeBSD.org

--- Comment #3 from Warner Losh <imp@FreeBSD.org> ---
> There should be some safety code to avoid any kernel panic on this usecase (as the data disk which hold ext3fs was distinct from the system disk).

Of course. That's what makes this a bug. There's a fair amount of code already
that tries to return an error rather than use erroneous data, but inside and
outside of ext3fs code. Of course it shouldn't panic.

To help make this bug report actionable, however, a more complete way to
reproduce this would be useful. The description is a good start, but what
options do I need to pass to rsync? What kind of files are required in the ZFS
dataset? How many? What sizes? etc. The corruption could come from ext2fs.ko,
zfs.ko or something else that's impossible to guess given the current
information.

Also, what was the corruption in UFS? On crashes, the superblocks and other
metadata, let alone dirty data pages, aren't pushed out to disk (since when the
system panics, it's hard to know if you are syncing good data, junk or if
syncing is even possible given the damage). fsck will repair these problems,
though. So more information about the corruption on the UFS partitions, and
what options were used to create them would also help us know if that part of
the bug is 'expected inflight operation uncertainty at the time of panic' or if
its something new that also needs to be investigated.

-- 
You are receiving this mail because:
You are the assignee for the bug.