Guys.... Is a panic **really** appropriate for a filesystem that isn't even in fstab? ie; panic: ufs_dirbad: /mnt: bad dir ino 3229 at offset 0: mangled entry Which happened to be an file-backed md volume that got changed as I forgot to unmount it beforehand, however as a result there is now inconsistencies and probably data corruption or even missing data on other important filesystems (ie; /, /var etc) because there wasn't even a sync or any kind of other sensible behaviour. This is on a production box, which also has gmirror so I now have no idea what state it's going to be in when I can get a display attached. Surely the appropriate response here for non-critical filesystems is to warn and suggest manually inspecting it as turning a working production box into one thats dead in the water seems a little extreme. J
Guys.... Is a panic **really** appropriate for a filesystem that isn't even in fstab? ie; panic: ufs_dirbad: /mnt: bad dir ino 3229 at offset 0: mangled entry Which happened to be an file-backed md volume that got changed as I forgot to unmount it beforehand, however as a result there is now inconsistencies and probably data corruption or even missing data on other important filesystems (ie; /, /var etc) because there wasn't even a sync or any kind of other sensible behaviour. This is on a production box, which also has gmirror so I now have no idea what state it's going to be in when I can get a display attached. Surely the appropriate response here for non-critical filesystems is to warn and suggest manually inspecting it as turning a working production box into one thats dead in the water seems a little extreme. J
On Sat, Jan 14, 2012 at 8:20 PM, Joe Holden <jwhlists@gmail.com> wrote:> ?Guys.... > > Is a panic **really** appropriate for a filesystem that isn't even in > fstab? > > ie; > panic: ufs_dirbad: /mnt: bad dir ino 3229 at offset 0: mangled entry > > Which happened to be an file-backed md volume that got changed as I forgot > to unmount it beforehand, however as a result there is now inconsistencies > and probably data corruption or even missing data on other important > filesystems (ie; /, /var etc) because there wasn't even a sync or any kind > of other sensible behaviour. > > This is on a production box, which also has gmirror so I now have no idea > what state it's going to be in when I can get a display attached. > > Surely the appropriate response here for non-critical filesystems is to > warn and suggest manually inspecting it as turning a working production box > into one thats dead in the water seems a little extreme.That's usually the sign that something went bonkers with the underlying filesystem to the extent that it's corrupt beyond all repair. In this case though, I wouldn't necessarily say that the md-backed filesystem is the one that's corrupt -- it might be the root filesystem. What version of FreeBSD are you using and what do you have enabled in the filesystem (FFS, UFS1, UFS2, SU, SUJ..)? Thanks, -Garrett
Am 15.01.2012 um 05:20 schrieb Joe Holden:> Guys.... > > Is a panic **really** appropriate for a filesystem that isn't even in > fstab? > > ie; > panic: ufs_dirbad: /mnt: bad dir ino 3229 at offset 0: mangled entry > > Which happened to be an file-backed md volume that got changed as I forgot > to unmount it beforehand, however as a result there is now inconsistencies > and probably data corruption or even missing data on other important > filesystems (ie; /, /var etc) because there wasn't even a sync or any kind > of other sensible behaviour.Yes, a panic is the correct action here. While I agree that it's super annoying, the filesystem notices that something is *really* wrong. Instead of letting the problem fester and continue to corrupt data, it stops the system. Most filesystems work under the assumption that they're the sole owner of the disk. This means that any changes to the on-disk data must come from filesystem code itself; if that data is inconstistent, it must be a bug in the filesystem code. At this point, panic is the only course of action to avoid even greater damage to the data. In other words: don't do that then :-) Stefan -- Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811