UFS ls on UFS2 partition freezes

Hi,

I have a UFS2 partition that I created with parted on Linux, and formatted on FreeBSD 10.0-RELEASE with newfs -O 2 -b 8192 -f 1024 /dev/ada1s8. This partition is for sharing data between FreeBSD, OpenBSD and Linux (it's not inside the FreeBSD slice). It worked fine in FreeBSD 10.0-RELEASE (read-write), it works in OpenBSD 5.6 (read-write) and it works in Linux (read-only).

I did a fresh install of FreeBSD 10.1-RELEASE. I mount the partition as usual with mount -t ufs /dev/ada1s8 /dataufs. This appears to work fine ( mount does not indicate any error). But when I run ls /dataufs, the ls command freezes forever, uses 100% CPU and can't be killed in any way.
  • ^C does not kill ls.
  • ^Z to send ls to the background does not work. The whole TTY is frozen.
  • Going to another TTY, logging in as root and running kill -9 on the ls process does not kill the ls process.
  • umount /dataufs does not work, and the umount process freezes exactly like ls (the TTY becomes unusable and the process can't be killed in any way).
I can switch to yet another TTY and run shutdown -r now. This sometimes reboots the system (after a long wait, presumably it waits for ls and umount to die), but sometimes the whole system freezes and does not reboot no matter how long I wait, requiring a hard reboot.

Upon booting into FreeBSD again, /dev/ada1s8 is marked as dirty. I can run fsck -y on it, which corrects approximately a few dozen to hundred errors about block sizes. Attempting to mount it again results in the same freeze.

(I have backups, so I recreate the filesystem and restore the files at this point.)

The really strange thing is that if I (in FreeBSD) run newfs -O 2 -b 8192 -f 1024 /dev/ada1s8 then the partition works, can be mounted, ls works, and I can use it normally. However when I reboot FreeBSD and attempt to use the partition, then the freeze happens again (I can reproduce it every time without exception and I have gone through this 5-10 times now). When I recreate the filesystem with newfs, then I can use it again until I reboot.

I can run dumpfs on the partition (in FreeBSD) and everything looks sane. I can also mount the partition on Linux (read-only because the kernel doesn't support UFS2 read-write) and access all files without any problems, and the partition works fine in OpenBSD (read-write). smartctl says the disk is in perfect condition and the self-tests return no errors (as expected because the disk is new).

I expect downgrading to FreeBSD 10.0-RELEASE will solve the problem, but surely this is not supposed to happen so I thought it would be appropriate to start a thread about it.

I use FreeBSD 10.1-RELEASE i386 and the hard drive is a Western Digital SATA disk. I used the same disk with FreeBSD 10.0-RELEASE (when everything worked).

Any ideas?
 
It does not sound like a hardware problem, although it would be nice to hear that it is not a WD Green disk. The first thing I would suggest is reformatting the partition with the defaults from newfs(8) for block and fragment sizes. The only other thing that is a little unusual is the slice number, which is likely an extended MBR slice. That should be fine, the only concern would be if it was to be used for booting.
 
It does not sound like a hardware problem, although it would be nice to hear that it is not a WD Green disk.
It's a WD Caviar Blue.

The first thing I would suggest is reformatting the partition with the defaults from newfs(8) for block and fragment sizes.
I used newfs -O 2 /dev/ada1s8 and it seems to work now, even after a reboot. Thanks a lot.

The only other thing that is a little unusual is the slice number, which is likely an extended MBR slice. That should be fine, the only concern would be if it was to be used for booting.
That's correct, it's a "logical" MBR partition. It only contains personal files. I don't even have it in /etc/fstab yet.
 
Nope. Here is what I did:
  1. I formatted the partition as you advised (on FreeBSD).
  2. I created a file on the partition.
  3. I rebooted (into FreeBSD).
  4. I successfully accessed the file. This never worked before, so I assumed the problem was gone now. (This is when I wrote my previous post.)
  5. I booted into OpenBSD and restored my backups to the partition (nothing special, just cp).
  6. I booted into FreeBSD and tried to print out a file on /dev/ada1s8 (with cat). This crashed the operating system and wrote a core dump to /var/crash. It didn't freeze this time and I didn't have to do a hard reboot.
Is it possible that OpenBSD does something to the filesystem so FreeBSD can't use it any more? The problem does seem to appear in step 5 (restoring the backups).
 
-O2 is a default, too.

FreeBSD and OpenBSD might not be write-compatible for UFS. Either or both might have diverged from the original. Ideally, only one operating system would write to a filesystem, and the problem would never come up. Maybe you can use a VM as a sort of NAS? If that's not possible, it's best to talk to the OpenBSD guys, or try UFS1.
 
I thought they were standardized! But I see now that there are no guarantees.

I noticed that OpenBSD has a newfs -O 0 option (which is not documented in FreeBSD's manual), maybe that's useful here:

newfs said:
4.3BSD format file system. This option is primarily used to build root file systems that can be understood by older boot ROMs.

I'll use a synchronized EXT2 filesystem to be safe. Thanks again.
 
A couple of thoughts came to mind while reading through the posts. Is it possible to run a top -P or a similar top(1) command, on a different tty(1), just prior to attempting the ls(1) command? That way, you would be able to monitor the processes that occur during the apparent "freeze", and better deduce the culprit. It might also be easier to maintain an FS type that they all happily read/write (see; support). Something FUSE based (sysutils/fuse-libs) for example might be a good choice. All the systems you indicate you're using, support it, and FreeBSD will even let you compile a kernel that permits using fusefs as a system mount. You could, of course, also kldload(8) it.
Just some thoughts. :)

HTH

--Chris
 
Back
Top