Re: [NetBSD 8.0] Another panic in ffs_newvnode()

[christos%astron.com@localhost (Christos Zoulas)]

In article <1C09D07D-E01F-4B77-AD31-04CF5792B579%eis.cs.tu-bs.de@localhost>,
J. Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost> wrote:
>
>> On 8. Jul 2017, at 22:56, BERTRAND Joël <joel.bertrand%systella.fr@localhost> wrote:
>> 
>> 	Hello,
>> 
>> 	This evening, my server running NetBSD 8.0 (built from sources this
>morning) has paniced :
>> 
>> legendre# crash -M netbsd.4.core -N netbsd.4
>> Crash version 8.0_BETA, image version 8.0_BETA.
>> System panicked: ffs_newvnode: dup alloc ino=1109312 on /usr: mode
>2f20/2f20 gen 65642f6a/65642f6a size 726964747365642f blocks
>752f3436646d612e
>
>Looks like a corrupted file system, we expect inode 1109312 on /usr
>to be unallocated but reading it from disk results in an inode with
>mode 0x2f20 (chr, sticky, suid, sgid, mode rr-), looks like garbage.
>
>I suppose fsck will not complain about unallocated garbage inodes.
>
>Is the /usr file system UFS1 or UFS2, output of dumpfs could help.

Depending if the fs is ufs1 or ufs2 the zeroing of inodes happens
either at newfs time (ufs1) or opportunistically during cylinder
group creation (ufs2). When a new inode is created, it is checked
for zero and if it is not zero, then you get the dup alloc panic.
This is done to prevent a confused filesystem to override existing
inode data.

If you see this again, your best bet is to copy the data somewhere
else, newfs the fs, and put the data back. If you are still seeing
the problem, then we have a genuine bug.

christos