How to Force fsck for all other non-root partitions
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
We have the following disks and there mount point:
/dev/sdb /appTdb/sdc ext4 defaults,noatime 0 0
/dev/sdc /appTdb/sdd ext4 defaults,noatime 0 0
/dev/sdd /appTdb/sde ext4 defaults,noatime 0 0
/dev/sde /appTdb/sdb ext4 defaults,noatime 0 0
We want to enable fsck on disks - sdb - sde , ( I mean to run fsck during boot )
so we set "1" in this fstab:
/dev/sdb /appTdb/sdc ext4 defaults,noatime 0 1
/dev/sdc /appTdb/sdd ext4 defaults,noatime 0 1
/dev/sdd /appTdb/sde ext4 defaults,noatime 0 1
/dev/sde /appTdb/sdb ext4 defaults,noatime 0 1
first question - is it correct
second what are the ether values that we can set instead "1" ,
for example 3 or 4 etc ( and what each value mean ? )
linux rhel fstab reboot fsck
edited Apr 29 at 13:37
GAD3R
22.2k154891
asked Apr 29 at 13:34
yael
1,9351144
add a comment |Â
up vote
2
down vote
favorite
We have the following disks and there mount point:
/dev/sdb /appTdb/sdc ext4 defaults,noatime 0 0
/dev/sdc /appTdb/sdd ext4 defaults,noatime 0 0
/dev/sdd /appTdb/sde ext4 defaults,noatime 0 0
/dev/sde /appTdb/sdb ext4 defaults,noatime 0 0
We want to enable fsck on disks - sdb - sde , ( I mean to run fsck during boot )
so we set "1" in this fstab:
/dev/sdb /appTdb/sdc ext4 defaults,noatime 0 1
/dev/sdc /appTdb/sdd ext4 defaults,noatime 0 1
/dev/sdd /appTdb/sde ext4 defaults,noatime 0 1
/dev/sde /appTdb/sdb ext4 defaults,noatime 0 1
first question - is it correct
second what are the ether values that we can set instead "1" ,
for example 3 or 4 etc ( and what each value mean ? )
linux rhel fstab reboot fsck
edited Apr 29 at 13:37
GAD3R
22.2k154891
asked Apr 29 at 13:34
yael
1,9351144
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
We have the following disks and there mount point:
/dev/sdb /appTdb/sdc ext4 defaults,noatime 0 0
/dev/sdc /appTdb/sdd ext4 defaults,noatime 0 0
/dev/sdd /appTdb/sde ext4 defaults,noatime 0 0
/dev/sde /appTdb/sdb ext4 defaults,noatime 0 0
We want to enable fsck on disks - sdb - sde , ( I mean to run fsck during boot )
so we set "1" in this fstab:
/dev/sdb /appTdb/sdc ext4 defaults,noatime 0 1
/dev/sdc /appTdb/sdd ext4 defaults,noatime 0 1
/dev/sdd /appTdb/sde ext4 defaults,noatime 0 1
/dev/sde /appTdb/sdb ext4 defaults,noatime 0 1
first question - is it correct
second what are the ether values that we can set instead "1" ,
for example 3 or 4 etc ( and what each value mean ? )
linux rhel fstab reboot fsck
edited Apr 29 at 13:37
GAD3R
22.2k154891
asked Apr 29 at 13:34
yael
1,9351144
We have the following disks and there mount point:
/dev/sdb /appTdb/sdc ext4 defaults,noatime 0 0
/dev/sdc /appTdb/sdd ext4 defaults,noatime 0 0
/dev/sdd /appTdb/sde ext4 defaults,noatime 0 0
/dev/sde /appTdb/sdb ext4 defaults,noatime 0 0
We want to enable fsck on disks - sdb - sde , ( I mean to run fsck during boot )
so we set "1" in this fstab:
/dev/sdb /appTdb/sdc ext4 defaults,noatime 0 1
/dev/sdc /appTdb/sdd ext4 defaults,noatime 0 1
/dev/sdd /appTdb/sde ext4 defaults,noatime 0 1
/dev/sde /appTdb/sdb ext4 defaults,noatime 0 1
first question - is it correct
second what are the ether values that we can set instead "1" ,
for example 3 or 4 etc ( and what each value mean ? )
linux rhel fstab reboot fsck
edited Apr 29 at 13:37
GAD3R
22.2k154891
asked Apr 29 at 13:34
yael
1,9351144
edited Apr 29 at 13:37
GAD3R
22.2k154891
edited Apr 29 at 13:37
GAD3R
22.2k154891
edited Apr 29 at 13:37
GAD3R
22.2k154891
22.2k154891
asked Apr 29 at 13:34
yael
1,9351144
asked Apr 29 at 13:34
yael
1,9351144
asked Apr 29 at 13:34
yael
1,9351144
1,9351144
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
IIRC, the numbers are just the order which disks get scanned before others. So, if 1 is used for all disks, then all the disks have the same priority for scanning. If one disk fails, then the boot fails, but it could be any of the disks that causes the failure. Using, say, 2 on some of the disks will cause those disks to be scanned after the ones given a 1. e.g.
/dev/sdb /appTdb/sdc ext4 defaults,noatime 0 1
/dev/sdc /appTdb/sdd ext4 defaults,noatime 0 2
/dev/sdd /appTdb/sde ext4 defaults,noatime 0 2
/dev/sde /appTdb/sdb ext4 defaults,noatime 0 3
In this case, disk /dev/sdb will be scanned first, then /dev/sdc and /dev/sdd, and finally /dev/sde. This could make a difference in your boot sequence, for example if /dev/sdb was the boot drive. A failure there would be a problem, whereas a failure on the the other drives could potentially be ignored if not critical.
Incidentally, why are your drives and mount points messed up? Usually, they match so that it is mentally easier to map mount point to device.
answered Apr 29 at 17:28
casualunixer
4651716
If you are already at the point of scanning in the boot process, it doesn't really matter if /dev/sdb contains boot or not. I'd be more woried about the root fs.
– Tim
May 3 at 21:36
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
IIRC, the numbers are just the order which disks get scanned before others. So, if 1 is used for all disks, then all the disks have the same priority for scanning. If one disk fails, then the boot fails, but it could be any of the disks that causes the failure. Using, say, 2 on some of the disks will cause those disks to be scanned after the ones given a 1. e.g.
/dev/sdb /appTdb/sdc ext4 defaults,noatime 0 1
/dev/sdc /appTdb/sdd ext4 defaults,noatime 0 2
/dev/sdd /appTdb/sde ext4 defaults,noatime 0 2
/dev/sde /appTdb/sdb ext4 defaults,noatime 0 3
In this case, disk /dev/sdb will be scanned first, then /dev/sdc and /dev/sdd, and finally /dev/sde. This could make a difference in your boot sequence, for example if /dev/sdb was the boot drive. A failure there would be a problem, whereas a failure on the the other drives could potentially be ignored if not critical.
Incidentally, why are your drives and mount points messed up? Usually, they match so that it is mentally easier to map mount point to device.
answered Apr 29 at 17:28
casualunixer
4651716
If you are already at the point of scanning in the boot process, it doesn't really matter if /dev/sdb contains boot or not. I'd be more woried about the root fs.
– Tim
May 3 at 21:36
add a comment |Â
up vote
2
down vote
accepted
IIRC, the numbers are just the order which disks get scanned before others. So, if 1 is used for all disks, then all the disks have the same priority for scanning. If one disk fails, then the boot fails, but it could be any of the disks that causes the failure. Using, say, 2 on some of the disks will cause those disks to be scanned after the ones given a 1. e.g.
/dev/sdb /appTdb/sdc ext4 defaults,noatime 0 1
/dev/sdc /appTdb/sdd ext4 defaults,noatime 0 2
/dev/sdd /appTdb/sde ext4 defaults,noatime 0 2
/dev/sde /appTdb/sdb ext4 defaults,noatime 0 3
In this case, disk /dev/sdb will be scanned first, then /dev/sdc and /dev/sdd, and finally /dev/sde. This could make a difference in your boot sequence, for example if /dev/sdb was the boot drive. A failure there would be a problem, whereas a failure on the the other drives could potentially be ignored if not critical.
Incidentally, why are your drives and mount points messed up? Usually, they match so that it is mentally easier to map mount point to device.
answered Apr 29 at 17:28
casualunixer
4651716
If you are already at the point of scanning in the boot process, it doesn't really matter if /dev/sdb contains boot or not. I'd be more woried about the root fs.
– Tim
May 3 at 21:36
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
IIRC, the numbers are just the order which disks get scanned before others. So, if 1 is used for all disks, then all the disks have the same priority for scanning. If one disk fails, then the boot fails, but it could be any of the disks that causes the failure. Using, say, 2 on some of the disks will cause those disks to be scanned after the ones given a 1. e.g.
/dev/sdb /appTdb/sdc ext4 defaults,noatime 0 1
/dev/sdc /appTdb/sdd ext4 defaults,noatime 0 2
/dev/sdd /appTdb/sde ext4 defaults,noatime 0 2
/dev/sde /appTdb/sdb ext4 defaults,noatime 0 3
In this case, disk /dev/sdb will be scanned first, then /dev/sdc and /dev/sdd, and finally /dev/sde. This could make a difference in your boot sequence, for example if /dev/sdb was the boot drive. A failure there would be a problem, whereas a failure on the the other drives could potentially be ignored if not critical.
Incidentally, why are your drives and mount points messed up? Usually, they match so that it is mentally easier to map mount point to device.
answered Apr 29 at 17:28
casualunixer
4651716
IIRC, the numbers are just the order which disks get scanned before others. So, if 1 is used for all disks, then all the disks have the same priority for scanning. If one disk fails, then the boot fails, but it could be any of the disks that causes the failure. Using, say, 2 on some of the disks will cause those disks to be scanned after the ones given a 1. e.g.
/dev/sdb /appTdb/sdc ext4 defaults,noatime 0 1
/dev/sdc /appTdb/sdd ext4 defaults,noatime 0 2
/dev/sdd /appTdb/sde ext4 defaults,noatime 0 2
/dev/sde /appTdb/sdb ext4 defaults,noatime 0 3
In this case, disk /dev/sdb will be scanned first, then /dev/sdc and /dev/sdd, and finally /dev/sde. This could make a difference in your boot sequence, for example if /dev/sdb was the boot drive. A failure there would be a problem, whereas a failure on the the other drives could potentially be ignored if not critical.
Incidentally, why are your drives and mount points messed up? Usually, they match so that it is mentally easier to map mount point to device.
answered Apr 29 at 17:28
casualunixer
4651716
answered Apr 29 at 17:28
casualunixer
4651716
answered Apr 29 at 17:28
casualunixer
4651716
answered Apr 29 at 17:28
casualunixer
4651716
4651716
If you are already at the point of scanning in the boot process, it doesn't really matter if /dev/sdb contains boot or not. I'd be more woried about the root fs.
– Tim
May 3 at 21:36
add a comment |Â
If you are already at the point of scanning in the boot process, it doesn't really matter if /dev/sdb contains boot or not. I'd be more woried about the root fs.
– Tim
May 3 at 21:36
If you are already at the point of scanning in the boot process, it doesn't really matter if /dev/sdb contains boot or not. I'd be more woried about the root fs.
– Tim
May 3 at 21:36
If you are already at the point of scanning in the boot process, it doesn't really matter if /dev/sdb contains boot or not. I'd be more woried about the root fs.
– Tim
May 3 at 21:36
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f440732%2fhow-to-force-fsck-for-all-other-non-root-partitions%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
