UFS UFS SU+J or gjournal?

[olli@]

UFS sucks, slow and buggy. Buy better hardware and go with ZFS.

I don't know what “UFS” you're talking about, but apparently not about UFS / FFS2 in FreeBSD. In the comparisons I performed, it is not slow at all. And if you know about any bugs, you should submit a report to bugs.freebsd.org – I'm sure that Kirk will fix it quickly.

 

[olli@]

About buggy. I used to have electricity out when the system was running. When it's back the system boot up slower because of some fsck, but finally got up and running. I see my files are still there (text files) and attempt to open it, I see nothing, the file is 0KB, f*ck.

Ok, you're angry because you lost data. That explains why you resort to swearing.

Upon a crash, when the meta data is synced to disk, but the actual data hasn't been synced yet, you get zero-size files. That's how soft-updates work. It's not a bug.

You wrote “buy better hardware” – Well, if you're prone to power failures, you'd better buy a UPS. It's definitely worth it. I also had a small UPS when I lived in an area prone to power outages. Saved me a lot of trouble.

 

[ralphbsz]

UFS sucks, slow and buggy. Buy better hardware and go with ZFS.

Nonsense. And repeating the offensive nonsense doesn't make it any more right.

 

[ralphbsz]

About buggy. I used to have electricity out when the system was running. When it's back the system boot up slower because of some fsck, but finally got up and running. I see my files are still there (text files) and attempt to open it, I see nothing, the file is 0KB, f*ck.

That is exactly the correct and expected behavior. If an application creates a file, writes to it, and does NOT call fsync() or some variant of it, and then the system crashes, the files are allowed (one might even say expected) to be zero size. There is no requirement that the data be saved. Don't believe me? Read the POSIX spec for open, write, close, and sync, and find some place where there is a guarantee that in case of a system crash the data will be saved without a sync.

 

[badbrain]

That is exactly the correct and expected behavior. If an application creates a file, writes to it, and does NOT call fsync() or some variant of it, and then the system crashes, the files are allowed (one might even say expected) to be zero size. There is no requirement that the data be saved. Don't believe me? Read the POSIX spec for open, write, close, and sync, and find some place where there is a guarantee that in case of a system crash the data will be saved without a sync.

But on Windows Word still have my file there despite with old content. So POSIX sucks.

 

[SirDice]

But on Windows Word still have my file there despite with old content.

Word saves backup documents, that has nothing to do with the filesystem.

 

[ralphbsz]

Same works with emacs on any Unix: The old document is still there (typically with a "~" after the name), and edits are saved, typically every few seconds (the file name of that backup file starts with "#"). So even if the system completely crashes, you don't lose more than a few seconds of work (typically none).

 

[Alexander Huemeyer]

Word saves backup documents, that has nothing to do with the filesystem.

Sames goes for Libre/OpenOffice. A Filesystem has to ensure metadata is correct. Everything else is up to you and the applications u use.

 

[Crivens]

But on Windows Word still have my file there despite with old content. So POSIX sucks.

We have ä proverb here: if the hillbilly can't swim, it's the fault of his swimming trunks.

Whatever Word does is of no concern to UFS or NTFS even. None, nada, nil. You may read up on NTFS and the journaling in it and compare it to a set of other file systems. They share a lot of concepts. And problems.

 

[garry]

UFS sucks, slow ..... go with ZFS.

One might have thought so. But when I needed to stripe two WD Red 1 TB HDD together for fast A/V media I tested both ZFS striped and UFS/SU on GEOM stripe. Bonnie++ benchmarks were run on each setup: UFS on gstripe was 50% faster read and 10% faster write than ZFS on the same disks. UFS also proved to be very reliable. Try it, you may be suprised at how good UFS actually is.

 

[olli@]

Actually I don't think that UFS and ZFS compete with each other. They complement each other. Both of them have their use cases – There are cases where UFS is more appropriate, and there are cases where ZFS is better. You can even combine them, like creating a UFS on top of a ZFS volume, although the use cases for such a setup are rather limited.

Finally, there are also cases where neither UFS nor ZFS is the best choice. For /tmp it's usually best to mount TMPFS on it, unless you're very short of RAM – in this case you should use a UFS partition with the async option or soft-updates (but without journaling).

Also, for exchange with non-FreeBSD systems, you probably want to use something like exFAT or NTFS or even FAT32, depending on circumstances. For example, I use a USB3 SSD with NTFS for transferring video recordings, because neither my DVB-T2 receiver nor my HDMI recording box support UFS or ZFS, but FreeBSD supports NTFS (thanks to the ntfs-3g port via FUSE). The only drawback is that FreeBSD does not support UAS / UASP, so the SSD works much slower and without TRIM and NCQ support in FreeBSD (it's 4 to 5 times faster in Linux and Windows, and TRIM + NCQ work there). But that's a different story, not related to file systems.

 

[abishai]

You can even combine them, like creating a UFS on top of a ZFS volume, although the use cases for such a setup are rather limited.

FreeBSD as a bhyve guest, for example. But is this setup I disable journal completely.

 

[gpw928]

like creating a UFS on top of a ZFS volume, although the use cases for such a setup are rather limited.

Virtualisation brings these challenges, so I don't think they are limited. However, working out what is sane, and why, is something to exercise the grey cells.

Just last week, I managed to resist using a ufs file system, inside a virtual machine running on a KVM server providing VM storage in qcow2 format, on top of an xfs formatted file system provisioned by the Linux Volume Manager (LVM), with a physical volume presented via iSCSI, using a zvol on a ZFS server. So ufs, under xfs, under LVM, under iSCSI, under zvol, under ZFS (a FreeBSD VM client on a Linux KVM server using a FreeBSD ZFS storage server).

I did build it. just for fun. The advantage of this arrangement is that multiple VMs could have storage provisioned from a single (iSCSI based) file system on the KVM server, with local volume management. I really wanted that because it's both convenient and flexible.

Ultimately common sense prevailed, and I put each VM in native format on a separate iSCSI volume. So ufs, under iSCSI, under zvol, under ZFS -- much more sensible, but much less convenient to manage.

I'm sure that these sorts of arrangements will become increasingly common. One suspects that grief awaits the adventurous.

By the way, I have lived in the same rural location or the last decade. I would say I lose power unexpectedly at least 20 or 30 times a year. All my UFS file systems are mounted with the default (ufs, local, journaled soft-updates). I have never had data loss of the type that fsck could not repair. I have only just started to use ZFS as my default FreeBSD file system type, and still use a UFS root (mirror) on my ZFS server.