Brian McCann wrote: > Yes...I apologize...I did that when I built the file system with > "newfs -J". Here's the tunefs -p output for one of the file systems: > > # tunefs -p /dev/da2.journal > tunefs: ACLs: (-a) disabled > tunefs: MAC multilabel: (-l) disabled > tunefs: soft updates: (-n) disabled > tunefs: gjournal: (-J) enabled > tunefs: maximum blocks per file in a cylinder group: (-e) 2048 > 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) > > I'm concerned about this because the ones I've had problems with > recently are 1.1TB arrays...I've got 2 8.6TB arrays that are journaled > as well...and if I ever have to fsck them...that could take 1/2 the > day... > > Any other thoughts?
Ok. There was one person that complained about fsck on gjournal but not in the same context - he created the journal for gjournal on an existing file system and so destroyed a part of the data. I don't think this is related to your case. Does gjournal complain about your drive, for example that it doesn't support BIOFLUSH? Also, did fsck actually do something when it was started (did it find anything corrupted)?
Description: OpenPGP digital signature