Strange UFS write problem & SU+J "unexpected inconsistences" on 9.1-STABLE r253105 after it on OTHER filesystems.

[Lev Serebryakov]

Hello, Edward.
You wrote 23 сентября 2013 г., 2:43:23:


ETN> According to "man errno", 22 is EINVAL.  Which is... weird, to say the least.
ETN> What's below the filesystem?  I mean, what's the GEOM tree?
 It is typical for old-skool installation, with addition of UFS labels:

ada0 -MBR-> ada0s1 -BSD LABEL-> ada0s1[abdef].

Moutns are via UFS labels (not glabel!)

ufs/root == ada0s1a
ufs/var == ada0s1d
ufs/tmp == ada0s1e
ufs/usr == ada0s1f

/dev/ufs/root on / (ufs, local, soft-updates)
/dev/ufs/tmp on /tmp (ufs, local, journaled soft-updates)
/dev/ufs/usr on /usr (ufs, NFS exported, local, journaled soft-updates)
/dev/ufs/var on /var (ufs, local, journaled soft-updates)

Swap is configured via glabel

label/swap == ada0s1b

>> (2) How to avoid fsck refuses in such situations? Why OTHER (not ones with
>> write errors) FSes get errors? It looks like one another problem with SU+J.
ETN> Try to make fsck _not_ use journal.  Simply respond "n" when it asks if you want
ETN> it to use journal.
  /usr and /tmp were fixed by _not_ using journal, when I see that server goes
 to single-user mode. /var and / were fixed before that by fsck runs on boot
 sequence after this panic, so I leave them as-is, because, I didn't know
 about write errors at this moment...

>> Please note, these FSes reside directly on SATA drive, without any software or
>> hardware RAIDs.
ETN> No labels, for example?
 See above.

-- 
// Black Lion AKA Lev Serebryakov <lev at FreeBSD.org>