gjournal & fsck

[Ivan Voras]

Brian McCann wrote:
> On Thu, Aug 28, 2008 at 10:51 AM, Ivan Voras <ivoras at freebsd.org> wrote:
>> Does gjournal complain about your drive, for example that it doesn't
>> support BIOFLUSH?
> 
> Actually yes...I meant to post them in my last message, but hit send
> too early...here's my output from boot (from dmesg.boot)
> 
> GEOM_JOURNAL: Journal 478661671: da1 contains data.
> GEOM_JOURNAL: Journal 478661671: da1 contains journal.
> GEOM_JOURNAL: Journal da1 clean.
> (da1:mly0:4:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
> (da1:mly0:4:1:0): CAM Status: SCSI Status Error
> (da1:mly0:4:1:0): SCSI Status: Check Condition
> (da1:mly0:4:1:0): ILLEGAL REQUEST asc:24,0
> (da1:mly0:4:1:0): Invalid field in CDB
> (da1:mly0:4:1:0): Unretryable error
> GEOM_JOURNAL: BIO_FLUSH not supported by da1.
> GEOM_JOURNAL: Journal 3065355517: da2 contains data.
> GEOM_JOURNAL: Journal 3065355517: da2 contains journal.
> GEOM_JOURNAL: Journal da2 clean.
> (da2:mly1:4:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
> (da2:mly1:4:0:0): CAM Status: SCSI Status Error
> (da2:mly1:4:0:0): SCSI Status: Check Condition
> (da2:mly1:4:0:0): ILLEGAL REQUEST asc:24,0
> (da2:mly1:4:0:0): Invalid field in CDB
> (da2:mly1:4:0:0): Unretryable error
> GEOM_JOURNAL: BIO_FLUSH not supported by da2.

>> Also, did fsck actually do something when it was started (did it find
>> anything corrupted)?
>>
> No...it didn't find anything wrong / anything to fix.  (and one of the
> file systems was being written to at the time...so at least journaling
> appears to be working)  Something else I noticed...Manolis' article
> says it should say "journal xxxx consistent"...whereas mine says
> "Journal xxxx clean".  I don't know what the differences mean, or what
> the BIO_FLUSH means...but I'm hoping you can tell me. :)

Ok, this is most probably the cause of your fsck. BIO_FLUSH is a
catch-all name for operations that synchronize (commit) the drive and
controller caches. It is used to synchronize the file system state after
it's been committed from the journal - if BIO_FLUSH succeeds the data is
guaranteed (or should be guaranteed) by hardware that it's safely
written. Since your controller doesn't support it you have a problem
here. Your best bet is to ask the author of the driver for your
controller (according to the "mly" man page this is Michael Smith
<msmith at FreeBSD.org>) if he knows anything that can help you here (maybe
the driver simply needs to implement it or fix it).

Other than that, you might disable write caching on your controller.
This should significantly reduce the cases where fsck would need to be
called on reboot, but probably not eliminate them completely. It will
also slow down the commit operation (from the journal to the active file
system) but if the server doesn't constantly write to the file system it
 won't be a big problem.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20080828/9e306e88/signature.pgp