How do I check how many times the root-file system can be mounted before it is auto checked? [duplicate]
This question already has an answer here:
What's the frequency of filesystem check on boot?
1 answer
How do I check how many times the root file system can be mounted before it is auto checked?
I'm wondering as I want to see on my system how many times it can be mounted.
16.04
marked as duplicate by RoVo, mikewhatever, steeldriver, karel, user68186 Jan 11 at 17:13
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
This question already has an answer here:
What's the frequency of filesystem check on boot?
1 answer
How do I check how many times the root file system can be mounted before it is auto checked?
I'm wondering as I want to see on my system how many times it can be mounted.
16.04
marked as duplicate by RoVo, mikewhatever, steeldriver, karel, user68186 Jan 11 at 17:13
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
This question already has an answer here:
What's the frequency of filesystem check on boot?
1 answer
How do I check how many times the root file system can be mounted before it is auto checked?
I'm wondering as I want to see on my system how many times it can be mounted.
16.04
This question already has an answer here:
What's the frequency of filesystem check on boot?
1 answer
How do I check how many times the root file system can be mounted before it is auto checked?
I'm wondering as I want to see on my system how many times it can be mounted.
This question already has an answer here:
What's the frequency of filesystem check on boot?
1 answer
16.04
16.04
asked Jan 11 at 16:41
AnthonyAnthony
92
92
marked as duplicate by RoVo, mikewhatever, steeldriver, karel, user68186 Jan 11 at 17:13
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by RoVo, mikewhatever, steeldriver, karel, user68186 Jan 11 at 17:13
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
If your root file system is ext4
, you can use tune2fs
to check (and also to modify) how many times it can be mounted before it is autochecked. See man tune2fs
,
-l List the contents of the filesystem superblock, including the
current values of the parameters that can be set via this program.
Using my root file system as an example:
sudo tune2fs -l /dev/sda1
or more focused
$ LANG=C sudo tune2fs -l /dev/sda1|grep -A4 'Mount count:'
[sudo] password for sudodus:
Mount count: 30
Maximum mount count: 40
Last checked: Tue Dec 25 05:50:43 2018
Check interval: 2592000 (1 month)
Next check after: Thu Jan 24 05:50:43 2019
You can have both a number of mount criterion and a time criterion, and (during boot) when the first criterion is satisfied, there will be a check.
Please notice that in many new versions (of tune2fs
and of linux file systems), mount-count-dependent checking is disabled by default to avoid unanticipated long reboots while e2fsck
does its work.
-c max-mount-counts
Adjust the number of mounts after which the filesystem will be checked by
e2fsck(8). If max-mount-counts is 0 or -1, the number of times the
filesystem is mounted will be disregarded by e2fsck(8) and the kernel.
Staggering the mount-counts at which filesystems are forcibly checked
will avoid all filesystems being checked at one time when using journaled
filesystems.
Mount-count-dependent checking is disabled by default to avoid unantici‐
pated long reboots while e2fsck does its work. However, you may wish to
consider the consequences of disabling mount-count-dependent checking
entirely. Bad disk drives, cables, memory, and kernel bugs could all
corrupt a filesystem without marking the filesystem dirty or in error.
If you are using journaling on your filesystem, your filesystem will
never be marked dirty, so it will not normally be checked. A filesystem
error detected by the kernel will still force an fsck on the next reboot,
but it may already be too late to prevent data loss at that point.
See also the -i option for time-dependent checking.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
If your root file system is ext4
, you can use tune2fs
to check (and also to modify) how many times it can be mounted before it is autochecked. See man tune2fs
,
-l List the contents of the filesystem superblock, including the
current values of the parameters that can be set via this program.
Using my root file system as an example:
sudo tune2fs -l /dev/sda1
or more focused
$ LANG=C sudo tune2fs -l /dev/sda1|grep -A4 'Mount count:'
[sudo] password for sudodus:
Mount count: 30
Maximum mount count: 40
Last checked: Tue Dec 25 05:50:43 2018
Check interval: 2592000 (1 month)
Next check after: Thu Jan 24 05:50:43 2019
You can have both a number of mount criterion and a time criterion, and (during boot) when the first criterion is satisfied, there will be a check.
Please notice that in many new versions (of tune2fs
and of linux file systems), mount-count-dependent checking is disabled by default to avoid unanticipated long reboots while e2fsck
does its work.
-c max-mount-counts
Adjust the number of mounts after which the filesystem will be checked by
e2fsck(8). If max-mount-counts is 0 or -1, the number of times the
filesystem is mounted will be disregarded by e2fsck(8) and the kernel.
Staggering the mount-counts at which filesystems are forcibly checked
will avoid all filesystems being checked at one time when using journaled
filesystems.
Mount-count-dependent checking is disabled by default to avoid unantici‐
pated long reboots while e2fsck does its work. However, you may wish to
consider the consequences of disabling mount-count-dependent checking
entirely. Bad disk drives, cables, memory, and kernel bugs could all
corrupt a filesystem without marking the filesystem dirty or in error.
If you are using journaling on your filesystem, your filesystem will
never be marked dirty, so it will not normally be checked. A filesystem
error detected by the kernel will still force an fsck on the next reboot,
but it may already be too late to prevent data loss at that point.
See also the -i option for time-dependent checking.
add a comment |
If your root file system is ext4
, you can use tune2fs
to check (and also to modify) how many times it can be mounted before it is autochecked. See man tune2fs
,
-l List the contents of the filesystem superblock, including the
current values of the parameters that can be set via this program.
Using my root file system as an example:
sudo tune2fs -l /dev/sda1
or more focused
$ LANG=C sudo tune2fs -l /dev/sda1|grep -A4 'Mount count:'
[sudo] password for sudodus:
Mount count: 30
Maximum mount count: 40
Last checked: Tue Dec 25 05:50:43 2018
Check interval: 2592000 (1 month)
Next check after: Thu Jan 24 05:50:43 2019
You can have both a number of mount criterion and a time criterion, and (during boot) when the first criterion is satisfied, there will be a check.
Please notice that in many new versions (of tune2fs
and of linux file systems), mount-count-dependent checking is disabled by default to avoid unanticipated long reboots while e2fsck
does its work.
-c max-mount-counts
Adjust the number of mounts after which the filesystem will be checked by
e2fsck(8). If max-mount-counts is 0 or -1, the number of times the
filesystem is mounted will be disregarded by e2fsck(8) and the kernel.
Staggering the mount-counts at which filesystems are forcibly checked
will avoid all filesystems being checked at one time when using journaled
filesystems.
Mount-count-dependent checking is disabled by default to avoid unantici‐
pated long reboots while e2fsck does its work. However, you may wish to
consider the consequences of disabling mount-count-dependent checking
entirely. Bad disk drives, cables, memory, and kernel bugs could all
corrupt a filesystem without marking the filesystem dirty or in error.
If you are using journaling on your filesystem, your filesystem will
never be marked dirty, so it will not normally be checked. A filesystem
error detected by the kernel will still force an fsck on the next reboot,
but it may already be too late to prevent data loss at that point.
See also the -i option for time-dependent checking.
add a comment |
If your root file system is ext4
, you can use tune2fs
to check (and also to modify) how many times it can be mounted before it is autochecked. See man tune2fs
,
-l List the contents of the filesystem superblock, including the
current values of the parameters that can be set via this program.
Using my root file system as an example:
sudo tune2fs -l /dev/sda1
or more focused
$ LANG=C sudo tune2fs -l /dev/sda1|grep -A4 'Mount count:'
[sudo] password for sudodus:
Mount count: 30
Maximum mount count: 40
Last checked: Tue Dec 25 05:50:43 2018
Check interval: 2592000 (1 month)
Next check after: Thu Jan 24 05:50:43 2019
You can have both a number of mount criterion and a time criterion, and (during boot) when the first criterion is satisfied, there will be a check.
Please notice that in many new versions (of tune2fs
and of linux file systems), mount-count-dependent checking is disabled by default to avoid unanticipated long reboots while e2fsck
does its work.
-c max-mount-counts
Adjust the number of mounts after which the filesystem will be checked by
e2fsck(8). If max-mount-counts is 0 or -1, the number of times the
filesystem is mounted will be disregarded by e2fsck(8) and the kernel.
Staggering the mount-counts at which filesystems are forcibly checked
will avoid all filesystems being checked at one time when using journaled
filesystems.
Mount-count-dependent checking is disabled by default to avoid unantici‐
pated long reboots while e2fsck does its work. However, you may wish to
consider the consequences of disabling mount-count-dependent checking
entirely. Bad disk drives, cables, memory, and kernel bugs could all
corrupt a filesystem without marking the filesystem dirty or in error.
If you are using journaling on your filesystem, your filesystem will
never be marked dirty, so it will not normally be checked. A filesystem
error detected by the kernel will still force an fsck on the next reboot,
but it may already be too late to prevent data loss at that point.
See also the -i option for time-dependent checking.
If your root file system is ext4
, you can use tune2fs
to check (and also to modify) how many times it can be mounted before it is autochecked. See man tune2fs
,
-l List the contents of the filesystem superblock, including the
current values of the parameters that can be set via this program.
Using my root file system as an example:
sudo tune2fs -l /dev/sda1
or more focused
$ LANG=C sudo tune2fs -l /dev/sda1|grep -A4 'Mount count:'
[sudo] password for sudodus:
Mount count: 30
Maximum mount count: 40
Last checked: Tue Dec 25 05:50:43 2018
Check interval: 2592000 (1 month)
Next check after: Thu Jan 24 05:50:43 2019
You can have both a number of mount criterion and a time criterion, and (during boot) when the first criterion is satisfied, there will be a check.
Please notice that in many new versions (of tune2fs
and of linux file systems), mount-count-dependent checking is disabled by default to avoid unanticipated long reboots while e2fsck
does its work.
-c max-mount-counts
Adjust the number of mounts after which the filesystem will be checked by
e2fsck(8). If max-mount-counts is 0 or -1, the number of times the
filesystem is mounted will be disregarded by e2fsck(8) and the kernel.
Staggering the mount-counts at which filesystems are forcibly checked
will avoid all filesystems being checked at one time when using journaled
filesystems.
Mount-count-dependent checking is disabled by default to avoid unantici‐
pated long reboots while e2fsck does its work. However, you may wish to
consider the consequences of disabling mount-count-dependent checking
entirely. Bad disk drives, cables, memory, and kernel bugs could all
corrupt a filesystem without marking the filesystem dirty or in error.
If you are using journaling on your filesystem, your filesystem will
never be marked dirty, so it will not normally be checked. A filesystem
error detected by the kernel will still force an fsck on the next reboot,
but it may already be too late to prevent data loss at that point.
See also the -i option for time-dependent checking.
edited Jan 11 at 17:15
answered Jan 11 at 17:03
sudodussudodus
23.8k32874
23.8k32874
add a comment |
add a comment |