SoftUpdate with journaling decrease reliability?

RusDyr

Member

Reaction score: 15
Messages: 90

Good day, all.

I've got a dozen problems with my servers on the FreeBSD (9.0 and later) with turned on journaling with SoftUpdates on root slice (/). The problem is what filesystem stay inconsistently after hard reboot and fsck completed check filesystem with journaling use. Althrough it says filesystem is clean, it's not. In the worse case it leads to the reset loop (FreeBSD can't boot after single mode due filesystem is bad). The only way to fix it is to boot in single-user mode and start fsck twice. For example, one of the my server currently under threat (check from "work" mode):

[CMD=""]tunefs -p /[/CMD]
Code:
tunefs: POSIX.1e ACLs: (-a)                                disabled
tunefs: NFSv4 ACLs: (-N)                                   disabled
tunefs: MAC multilabel: (-l)                               disabled
tunefs: soft updates: (-n)                                 enabled
tunefs: soft update journaling: (-j)                       enabled
tunefs: gjournal: (-J)                                     disabled
tunefs: trim: (-t)                                         disabled
tunefs: maximum blocks per file in a cylinder group: (-e)  4096
tunefs: average file size: (-f)                            16384
tunefs: average number of files in a directory: (-s)       64
tunefs: minimum percentage of free space: (-m)             8%
tunefs: optimization preference: (-o)                      time
tunefs: volume label: (-L)
# fsck /
Code:
** /dev/label/rootfs (NO WRITE)

USE JOURNAL? no

** Skipping journal, falling through to full fsck

SETTING DIRTY FLAG IN READ_ONLY MODE

UNEXPECTED SOFT UPDATE INCONSISTENCY
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

126143 files, 1169116 used, 7085540 free (5004 frags, 885067 blocks, 0.1% fragmentation)

[CMD=""]uname -a[/CMD]
Code:
FreeBSD leht 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Fri Mar 16 05:08:15 MSK 2012     root@bsd9:/usr/obj/usr/src/sys/ROUTER_HOME_NETS  amd64
And that problem isn't unitary.
What's the caveat?
 

Terry_Kennedy

Aspiring Daemon

Reaction score: 285
Messages: 907

RusDyr said:
And that problem isn't unitary.
What's the caveat?
I don't know - it isn't a feature I use. If you don't get any better advice that "don't do that", you might want to consider not using soft updates on your root filesystem. If you have /tmp, /var, etc. on other partitions, there probably isn't enough file creation activity to benefit from SUJ (or even plain old soft updates) on your root partition.
 

mav@

Aspiring Daemon
Developer

Reaction score: 217
Messages: 702

Softupdates and softupdates/journaling are both based on the assumption that a device doesn't reorder write operations. If write operations were reordered and the disk was suddenly powered down, the filesystem state may become inconsistent, requiring a full long check. Fast journaled recovery assumes that it may not happen.

So you should either use UPS for your servers to shutdown them cleanly on power loss and let disks actually write all cached data, or disable disk write caches to prevent write reordering, or use full long foreground fsck.
 

Sfynx

Active Member

Reaction score: 13
Messages: 114

Theoretically, also a foreground fsck might not be able to fix all damage resulting from this. Disabling disk caches will completely kill performance, so IMO ZFS is the only option for modern drives that use things like NCQ, because it actually enforces a write order by use of BIO_FLUSH.
 

mav@

Aspiring Daemon
Developer

Reaction score: 217
Messages: 702

For drives with command queuing the performance penalty from disabled caches should be much smaller because multiple active commands are working alike to write cache. But unlike write cache queued commands are not lying to the FS, so the FS is able to properly handle request ordering without requiring explicit cache flushes.
 
Top