kern/56675 (mounting ext2fs gives bad shutdown) still a problem in 5.3RC1

[Stefek Zaba]

Head above parapet: I was bitten by outstanding bug kern/56675 during a 
trial install of 5.3RC1 - I'd mounted an ext3 partition (using ext2fs, 
since ext3 is "backwards compatible", loosely speaking), called shutdown 
to exit "cleanly" without a preceding umount of the ext3 partition, and 
had the "syncing disks, buffers remaning... n n n n n n n
giving up on n buffers" message as described in 56675.

56675 has been open since 10sep03 (filed against 5.1CURRENT), with a dup 
recorded and closed (as a dup) as 63398 against 5.2CURRENT on 27feb04, 
and another dup as kern/70834 as recently as 23aug04. The open one rates 
the Severity as Serious, and Priority as Medium. For a FreeBSD 
production install, that may even overstate the case, as there you'd be 
running all your mounted FSes as UFS, I presume. But for the 
multibooting dabblers with Penguin-flavoured data, it's kinda offputting 
to have their early encounters with FreeBSD marred by a dirty shutdown; 
and the text of these bugs allege that not only the e2fs data, but 
"central" UFS partitions, can also be corrupted by this. So in 
situations where ext2 partitions are in use, it's at least arguable that 
  the Severity is higher than Serious... and a fix to allow smoother 
coexistence with the ext2/ext3 world would be a welcome encouragement to 
a "low-risk" Just Try The BSD Way ;-)

I've no idea, though, whether this is a relatively quick fix that "just" 
needs an existing fs guru to spend a couple of hours of their (already 
overcommitted) time on, or whether there are dragons in the ext2fs code 
or its interactions with the rest of vnode handling which make this a 
well-known maintenance nightmare. Apologies in advance if I'm scratching 
at an open wound... And if it is a pain to fix, might there be any 
partial relief available by making shutdown umount non-UFS partitions 
"earlier"?

Stefek