FS not clean!

belhifet · 2007-05-04 19:36:24

Ok, each time I boot up, I get 2 messages to the end that are saying something along the lines of "xfs is clean" and "reiserfs is clean".
I use xfs for my / partition and reiserfs for my /home partition.

I accidentally did a reset and on this bootup, I got "xfs is NOT clean" and "reiserfs is NOT clean".
What does this mean and what can I do in order to fix this problem?

Also, I can't paste the exact message, because dmesg does not show all of the stuff I get on bootup.
Generally, it doesn't log stuff that get printed after the starting services procedure (with the cyan OKs to the right).
How can I see those after I have logged in?

[vEX] · 2007-05-04 21:15:01

It means that changes in the filesystem were queued up to be written to the disk but didn't get the chance since you rebooted. ReiserFS is journaling and I'm pretty sure XFS is too, which means that during the boot fcsk should have ran for those partitions and replayed the journal to get a clean system. Did you see anything like that when it booted?

If it didnt' run you need to boot of another partition and run fsck manually on those partitions while they're NOT mounted, for example you could boot the Arch install CD and from there run fsck. Check man pages for fsck for more information about the flags for it.

Not sure exactly where you can find the info after logging in, but I think the information from fsck (if it ran) is saved somewhere in /var/log/.

belhifet · 2007-05-04 21:19:26

I thought that journaled filesystems didn't need to be fscked.

No, I didn't see anything unusual during the booting process, except from those "NOT clean" messages.

What are the concequences of leaving them unfscked (being "NOT clean")?

byte · 2007-05-04 22:56:27

Every FS needs to be "clean", to be in a consistent state. Journaling filesystems just don't need to check each and every inode to be sure, they just replay their journal. Much quicker, less downtime. The downside is that it only ensures metadata integrity, it won't protect any actual file contents. Only exception: ext3 with data=journal mount option.
I'm not sure about the consequences, but I might add that I lost a whole directory tree (/usr/man, nothing fancy) after pressing 'reset' once. The filesystems were checked upon reboot and reported as clean. Adios data, didn't care, uptime is king.

belhifet · 2007-05-04 23:27:44

Oh noes.
I care.

What fs was that on /usr/man?

byte · 2007-05-04 23:56:35

JFS. But that doesn't matter, pressing Reset or losing power in the wrong moment would mean trouble with any filesystem.

EDIT: "wrong moment" = modified data is cached but not completely written to disk

Last edited by byte (2007-05-04 23:59:09)

belhifet · 2007-05-05 12:36:04

Isn't there a way to fsck the filesystems without booting off a livecd/rescuecd?

I think I read somewhere that at least reiserfs was taking care of those Reset situations.

belhifet · 2007-06-04 22:18:02

Well, after a few reboots, it said "FS is clean" for both partitions again.

I did not run fsck.

Is that normal?
Seems like it fixed itself or something...:/

ataraxia · 2007-06-04 23:00:43

XFS, at least, doesn't require fsck - if you look at fsck.xfs, it's a stub. When you try to mount a dirty XFS instance, it plays the journal, so it should fix itself that way. If you XFS gets really screwed up, it won't mount, and you have to use xfs_repair on it.

Arch Linux

#1 2007-05-04 19:36:24

FS not clean!

#2 2007-05-04 21:15:01

Re: FS not clean!

#3 2007-05-04 21:19:26

Re: FS not clean!

#4 2007-05-04 22:56:27

Re: FS not clean!

#5 2007-05-04 23:27:44

Re: FS not clean!

#6 2007-05-04 23:56:35

Re: FS not clean!

#7 2007-05-05 12:36:04

Re: FS not clean!

#8 2007-06-04 22:18:02

Re: FS not clean!

#9 2007-06-04 23:00:43

Re: FS not clean!

Board footer