"The Linux Gazette...making Linux just a little more fun!"

Maximal Mount Count Reached

From Marius Andreiana on Sat, 25 Sep 1999

Dear Answer Guy,

I'm Marius and here is my problem :

From time to time ( seldom ), my RH Linux 6.0 says during booting "/dev/hdaX had reached maximal mount count; check forced" where X is 3 and 4. Here's my partition table :

/dev/hda1,  170 MB, type= 6h   (DOS 16-bit >=32)
/dev/hda2,   16 MB, type=82h   (Linux swap)
/dev/hda3,  497 MB, type=83h   (Linux native)
/dev/hda4,  129 MB, type=83h   (Linux native)

I always perform clean shutdowns. I suppose this is because all the above 4 partitions are primary. But then why does it report that message only from time to time ?

Thanks a lot for your time
Marius

We call that "losing the lottery." It always seems to happen when you're in a hurry to get the system back up and running.

Don't worry about this message, though. It's perfectly normal. Even if you do cleanly shutdown every time, there's always that chance that some filesystem corruption has crept in. So each filesystem stores the number of times you've mounted it since you did an fsck (filesystem check) and automatically forces one at those points.

If you want to live dangerously you can change the the maximal mount count value on a filesystem using the 'tune2fs' command's -c option. You can also manually set the mount value using the -C (upper case) option. You can see the current values using a command like:

tune2fs -l /dev/hda1

... This is the only command that you might run on any of these devices while it is mounted. In my particular case it shows a maximal mount count of 20. You should unmount any filesystem before using tune2fs to write any new values unto them using the other options from this command. (It should be safe to change some values when you have a filesystem mounted read-only; though it might be worth asking an expert, so I've copied Ted T'so and Remy Card on this message).

You can also set a volume label on any of your ext2 filesystems using this command (BTW: 'tune2fs' only works on ext2fs --- don't try to use it on any other sorts of filesystems that you have). I notice that the man page doesn't tell us anything about these volume labels (like what characters are allowed, and how long they can be). Glancing at the source code to e2fsprogs I find that you can have volume labels of up to 16 characters. I didn't see any filtering on characters so I suppose any string of non-NUL characters might be used --- though I'd stick with simple alphanumerics and printable punctuation to be safe.

As far as I know there is no way in which this volume label is currently used. It seems to be a wholly optional feature; I guess we can use these to keep track of our removable media or something.

(Ted, Remy, is it safe to set some or all tune2fs values on a filesystem while it's mounted read-only? Are there any characters that should NOT be used in the volume labels? Is there anything that uses these volume labels, or are they just obscure cosmetic options?)

Having been cc'd, Ted T'so adds...

From tytso on Mon, 27 Sep 1999

Date: Sat, 25 Sep 1999 01:14:42 -0700 From: Jim Dennis <jimd@starshine.org>

We call that "losing the lottery." It always seems to happen when you're in a hurry to get the system back up and running.

Yup. Note that even once we have journalling support in ext2, you will want to occasionally force an fsck over the filesystem just to make sure there haven't been any errors caused by memory errors, disk errors, cosmic rays, etc.

If you need your laptop to reboot quickly just before a demo (and your laptop doesn't have a hiberate feature or some such), something you can do is to sync your disks, make sure your system is quiscient (i.e., nothing is running), and then force a power cycle and let your system reboot. Your system will then fsck all of your disks, and you can then shutdown your system, confident that the dreaded "maximal mount count" message won't appear during that critical demo.

If you want to live dangerously you can change the the maximal mount count value on a filesystem using the 'tune2fs' command's -c option. You can also manually set the mount value using the -C (upper case) option. You can see the current values using a command like:

tune2fs -l /dev/hda1

If you know that your system is fairly reliable --- you've been running it for a while and you're not seeing wierd failures due to cheasy cheap memory or overly long IDE or SCSI cables, etc. it's actually not so dangerous to set a longer maximal count time.

One approach if your system is constantly getting shutdown and restarted is to set the filesystem so it uses the time the filesystem was last checked as a criteria instead of a maximal count. For example:

tune2fs -c 100 -i 3m /dev/hda1

This will cause the filesystem to be checked after 100 mounts, or 3 months, whichever comes first.

(It should be safe to change some values when you have a filesystem mounted read-only; though it might be worth asking an expert, so I've copied Ted T'so and Remy Card on this message).

Yes, it's safe these values if the filesystem is mounted read-only. If you're ***sure*** that the filesystem is quiscent, and nothing is changing on the filesystem, you can even get away with changing it while the filesystem is mounted read-write. It's not something I'd really recommend, but if you know what you're doing, you can get away from it. It really depends on how much you like working without a safety net.

As far as I know there is no way in which this volume label is currently used. It seems to be a wholly optional feature; I guess we can use these to keep track of our removable media or something.

You can use the volume label in your /etc/fstab if you like: For example:

LABEL=temp /tmp ext2 defaults 1 2

or

UUID=3a30d6b4-08a5-11d3-91c3-e1fc5550af17 /usr ext2 defaults 1 2

The advantage of doing this is that the filesystems are specified in a device independent way. So for example, if your SCSI chain gets reordered, the filesystems will get mounted correctly even though the device names may have changed.

- Ted

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 48 December 1999

HTML transformation by Heather Stern of Starshine Technical Services, http://www.starshine.org/

					1	2	3	5
				5	6	7	8	9
10	11	12	13	14	15	16	17	18
19	20	21	22	23	24	25	26	27
28	29	30	31	32	33	34	35	36
37	38	39	40	41	42	43	44	45
46	47	48	49	50	51	52	53	54
55			56			57