I’m guessing the file system check is only performed during a boot? This warning message is nog going away. Just appears while the NAS boots. Everything is working fine.
The query is why can’t the MyBook Live do this WITHOUT user intervention? It should be automatic. I don’t want to be SSHing into the MBL, unmounding /dev/sda4, performing e2fsck (have you seen how many options it has?!) and then remounting /dev/sda4. That’s on top of stopping and restarting every process within the MBL once the check is done.
(Ok… A reboot is a simpler way of restarting all the services as they should be operating.)
Well, for one thing, the average user will never see that message.
Only people who are nosing around in the internal log will see that message.
Second, it’s not an indication of any error.
When EXT4 file systems are created, the journal maintains a count of the number of times the file system has been mounted / dismounted.
It only puts that message in the syslog when that count has been exceeded, and is not an indication of any issue.
So, it CAN do it, but it can be a lengthy process. Then people will complain “After I rebooted the box, it wasn’t working for the first 10 minutes!”
Then people won’t have any clue how to find the files it recovers (if any) because those are placed in lost+found directory which the user doesn’t have access to.
… but I would rather be able to get the file system checked every-so-often for inconsistancies and can pretty easily tollorate having the drive down for a while unless the quick disc check does a file system check? (Accessed from the Web UI)
What exact actions does the quick disc check take?
…it’s just generally not required for journaled file systems.
By default, all e2fsck does anyway is verify the integrety of the journal, and replay it if necessary.
I doubt the quick-check does any file system integrity checking… it’d have to dismount the volume to do it (just as you said.)
What normally happens in Linux boxes is, when the file system is mounted, it will do a quick check.
If there’s inconsistencies (an unclean shutdown can do this) it will re-play the journal into the file system and then check again. If there’s still an issue, it can do an FSCK itself before mounting.
I’m not sure, though, if the MBLs kernel is doing all that…
