Closed boricj closed 8 years ago
Issue #121 uncovered a way to reliably confuse VFS. With /dev/c0d0 being a 0's filled disk :
/dev/c0d0
minix# mount /dev/c0d0p0s0 /mnt mount cannot read super block on /dev/c0d0p0s0: Undefined error: 0 fs cache: I/O error on device 3/128, block 0 (0) mfs(65576): panic: MFS: error getting block (896,0): -5 syslib:panic.c: stacktrace: 0x8058ed6 0x80483fc 0x804dca6 0x804da15 0x8049535 0x80516b0 0x8050c95 0x8050d69 0x804cf4d 0x804828b 0x80481b8
The command hangs, as shown by ps :
ps
PID TT STAT TIME COMMAND 246 co D+ 0:00.02 mount /dev/c0d0p0s0 /mnt
Killing the mount command will put it in a zombie state until logout from the terminal. Running sync will also exhibit the same behavior.
mount
sync
For each new user logging in, VFS will output this :
VFS: path lookup error; root node not found
Thanks for the report - turns out there was "too much" crash recovery going on! This particular issue should be fixed now. I'd love to hear about any other problems in this department.
Issue #121 uncovered a way to reliably confuse VFS. With
/dev/c0d0
being a 0's filled disk :The command hangs, as shown by
ps
:Killing the
mount
command will put it in a zombie state until logout from the terminal. Runningsync
will also exhibit the same behavior.For each new user logging in, VFS will output this :