If “fsck -n /PATH” says errors, then it's 100% true that the FS has errors?
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
HOSTNAME:~ # fsck -n /FSMOUNTPOINT
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
Warning! /dev/vgname/lvname is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/vgname/lvname contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Inode 12845121 ref count is 1, should be 2. Fix? no
Inode 12845122 ref count is 1, should be 2. Fix? no
Inode 12845123 ref count is 1, should be 2. Fix? no
Inode 12845124 ref count is 1, should be 2. Fix? no
Pass 5: Checking group summary information
Free blocks count wrong (38829073, counted=37828469).
Fix? no
Free inodes count wrong (22658484, counted=22658235).
Fix? no
/dev/vgname/lvname: ********** WARNING: Filesystem still has errors **********
/dev/vgname/lvname: 16972/22675456 files (0.3% non-contiguous), 6521839/45350912 blocks
fsck.ext3 /dev/vgname/lvname failed (status 0x4). Run manually!
HOSTNAME:~ #
OS: SUSE LINUX Enterprise Server 9.4
FS: EXT3 with only rw options
Question: So if there is the "WARNING: Filesystem still has errors" message, I can be 100% sure that the FS has problems, and needs to be umount/fsck/mount'ed?
UPDATE:
$ tune2fs -l /dev/vgname/lvname | grep 'Filesystem state:'
Filesystem state: clean
$
fsck
asked Mar 27 '13 at 14:03
gasko peter
1,2511855122
|
show 1 more comment
up vote
1
down vote
favorite
HOSTNAME:~ # fsck -n /FSMOUNTPOINT
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
Warning! /dev/vgname/lvname is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/vgname/lvname contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Inode 12845121 ref count is 1, should be 2. Fix? no
Inode 12845122 ref count is 1, should be 2. Fix? no
Inode 12845123 ref count is 1, should be 2. Fix? no
Inode 12845124 ref count is 1, should be 2. Fix? no
Pass 5: Checking group summary information
Free blocks count wrong (38829073, counted=37828469).
Fix? no
Free inodes count wrong (22658484, counted=22658235).
Fix? no
/dev/vgname/lvname: ********** WARNING: Filesystem still has errors **********
/dev/vgname/lvname: 16972/22675456 files (0.3% non-contiguous), 6521839/45350912 blocks
fsck.ext3 /dev/vgname/lvname failed (status 0x4). Run manually!
HOSTNAME:~ #
OS: SUSE LINUX Enterprise Server 9.4
FS: EXT3 with only rw options
Question: So if there is the "WARNING: Filesystem still has errors" message, I can be 100% sure that the FS has problems, and needs to be umount/fsck/mount'ed?
UPDATE:
$ tune2fs -l /dev/vgname/lvname | grep 'Filesystem state:'
Filesystem state: clean
$
fsck
asked Mar 27 '13 at 14:03
gasko peter
1,2511855122
Checktune2fs -l /dev/vgname/lvname | grep 'Filesystem state:'
– jordanm
Mar 27 '13 at 14:12
I updated the q
– gasko peter
Mar 27 '13 at 14:27
You don't fsck a filesystem while it's mounted. Not even if it's mounted read-only.
– frostschutz
Mar 27 '13 at 14:48
@frostschutzfsck -non filesystems that support it is fine on aromounted filesystem.
– jordanm
Mar 27 '13 at 14:51
1
You're using LVM, so at minimum, take a snapshot and fsck that. Then there will not be concurrent writes, and you can allow journal recovery.
– derobert
Mar 27 '13 at 15:58
|
show 1 more comment
up vote
1
down vote
favorite
up vote
1
down vote
favorite
HOSTNAME:~ # fsck -n /FSMOUNTPOINT
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
Warning! /dev/vgname/lvname is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/vgname/lvname contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Inode 12845121 ref count is 1, should be 2. Fix? no
Inode 12845122 ref count is 1, should be 2. Fix? no
Inode 12845123 ref count is 1, should be 2. Fix? no
Inode 12845124 ref count is 1, should be 2. Fix? no
Pass 5: Checking group summary information
Free blocks count wrong (38829073, counted=37828469).
Fix? no
Free inodes count wrong (22658484, counted=22658235).
Fix? no
/dev/vgname/lvname: ********** WARNING: Filesystem still has errors **********
/dev/vgname/lvname: 16972/22675456 files (0.3% non-contiguous), 6521839/45350912 blocks
fsck.ext3 /dev/vgname/lvname failed (status 0x4). Run manually!
HOSTNAME:~ #
OS: SUSE LINUX Enterprise Server 9.4
FS: EXT3 with only rw options
Question: So if there is the "WARNING: Filesystem still has errors" message, I can be 100% sure that the FS has problems, and needs to be umount/fsck/mount'ed?
UPDATE:
$ tune2fs -l /dev/vgname/lvname | grep 'Filesystem state:'
Filesystem state: clean
$
fsck
asked Mar 27 '13 at 14:03
gasko peter
1,2511855122
HOSTNAME:~ # fsck -n /FSMOUNTPOINT
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
Warning! /dev/vgname/lvname is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/vgname/lvname contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Inode 12845121 ref count is 1, should be 2. Fix? no
Inode 12845122 ref count is 1, should be 2. Fix? no
Inode 12845123 ref count is 1, should be 2. Fix? no
Inode 12845124 ref count is 1, should be 2. Fix? no
Pass 5: Checking group summary information
Free blocks count wrong (38829073, counted=37828469).
Fix? no
Free inodes count wrong (22658484, counted=22658235).
Fix? no
/dev/vgname/lvname: ********** WARNING: Filesystem still has errors **********
/dev/vgname/lvname: 16972/22675456 files (0.3% non-contiguous), 6521839/45350912 blocks
fsck.ext3 /dev/vgname/lvname failed (status 0x4). Run manually!
HOSTNAME:~ #
OS: SUSE LINUX Enterprise Server 9.4
FS: EXT3 with only rw options
Question: So if there is the "WARNING: Filesystem still has errors" message, I can be 100% sure that the FS has problems, and needs to be umount/fsck/mount'ed?
UPDATE:
$ tune2fs -l /dev/vgname/lvname | grep 'Filesystem state:'
Filesystem state: clean
$
fsck
fsck
asked Mar 27 '13 at 14:03
gasko peter
1,2511855122
asked Mar 27 '13 at 14:03
gasko peter
1,2511855122
edited Mar 27 '13 at 14:26
asked Mar 27 '13 at 14:03
gasko peter
1,2511855122
asked Mar 27 '13 at 14:03
gasko peter
1,2511855122
asked Mar 27 '13 at 14:03
gasko peter
1,2511855122
1,2511855122
Checktune2fs -l /dev/vgname/lvname | grep 'Filesystem state:'
– jordanm
Mar 27 '13 at 14:12
I updated the q
– gasko peter
Mar 27 '13 at 14:27
You don't fsck a filesystem while it's mounted. Not even if it's mounted read-only.
– frostschutz
Mar 27 '13 at 14:48
@frostschutzfsck -non filesystems that support it is fine on aromounted filesystem.
– jordanm
Mar 27 '13 at 14:51
1
You're using LVM, so at minimum, take a snapshot and fsck that. Then there will not be concurrent writes, and you can allow journal recovery.
– derobert
Mar 27 '13 at 15:58
|
show 1 more comment
Checktune2fs -l /dev/vgname/lvname | grep 'Filesystem state:'
– jordanm
Mar 27 '13 at 14:12
I updated the q
– gasko peter
Mar 27 '13 at 14:27
You don't fsck a filesystem while it's mounted. Not even if it's mounted read-only.
– frostschutz
Mar 27 '13 at 14:48
@frostschutzfsck -non filesystems that support it is fine on aromounted filesystem.
– jordanm
Mar 27 '13 at 14:51
1
You're using LVM, so at minimum, take a snapshot and fsck that. Then there will not be concurrent writes, and you can allow journal recovery.
– derobert
Mar 27 '13 at 15:58
Check
tune2fs -l /dev/vgname/lvname | grep 'Filesystem state:'– jordanm
Mar 27 '13 at 14:12
Check
tune2fs -l /dev/vgname/lvname | grep 'Filesystem state:'– jordanm
Mar 27 '13 at 14:12
I updated the q
– gasko peter
Mar 27 '13 at 14:27
I updated the q
– gasko peter
Mar 27 '13 at 14:27
You don't fsck a filesystem while it's mounted. Not even if it's mounted read-only.
– frostschutz
Mar 27 '13 at 14:48
You don't fsck a filesystem while it's mounted. Not even if it's mounted read-only.
– frostschutz
Mar 27 '13 at 14:48
@frostschutz
fsck -n on filesystems that support it is fine on a ro mounted filesystem.– jordanm
Mar 27 '13 at 14:51
@frostschutz
fsck -n on filesystems that support it is fine on a ro mounted filesystem.– jordanm
Mar 27 '13 at 14:51
1
1
You're using LVM, so at minimum, take a snapshot and fsck that. Then there will not be concurrent writes, and you can allow journal recovery.
– derobert
Mar 27 '13 at 15:58
You're using LVM, so at minimum, take a snapshot and fsck that. Then there will not be concurrent writes, and you can allow journal recovery.
– derobert
Mar 27 '13 at 15:58
|
show 1 more comment
2 Answers
2
active
oldest
votes
up vote
5
down vote
accepted
The usual advice is to not run fsck on a mounted file system . You get unreliable results - while fsck is trying to scan the file system, the kernel is still reading and writing data to it, so it will appear, to fsck, inconsistent. Some file systems allow online use of fsck, but not all - FreeBSD, for example, can check a static snapshot of a UFS2 file system while it is in use, but you still wouldn't check the file system itself while it's mounted.
The best way to check your file system is to unmount it, then run fsck on it. If it still reports problems, you can take remedial action.
answered Mar 27 '13 at 14:48
D_Bye
10.4k13227
add a comment |
up vote
2
down vote
If fsck(8) says a filesystem has errors (in this case, the journal could't be replayed as it was mounted read-only, for starters), it has problems. You should shut down, start in maintenance mode (add single or 1 to the kernel line when booting; or even boot with install/rescue media) and do the full fsck. Check the manual for your exact filesystem, flags to use vary. Be careful! It asks for confirmation before doing some possibly dangerous operations. Most of the time you can't do anything byt say "yes" to everything, bu read what it says/asks.
Once you get the system working, find out what messed up the filesystem. It has been literally years with ext2/3/4 that I haven't seen filesystem corruption (but I don't just pull the plug or press the Big Red Button at random either...), so it could be bad handling or failing hardware. If the disk is failing, turn the machine off and get a replacement ASAP. Failing disks usually last hours (as in "a few", not as in "some hundred") before they are gone for good. Use that time to rescue your data, later you can do the autopsy to the failing disk at leisure. If it turns out to be a false alarm, you've got yourself space for the ripped CDs ;-)
answered Mar 27 '13 at 14:57
vonbrand
14.1k22644
I am in the opposite boat. I have seen tons of filesystem corruption in ext3 over the past few years. Granted, these servers stayed very heavily I/O loaded and there was a large pool (3,500) that could potentially have a problem. Most of the time it was related to some kind of hardware failure.
– jordanm
Mar 27 '13 at 15:09
Disks which are failing due to bad blocks can last a lot longer than hours if you fix the file system on them and add the bad blocks to the filesystem list, so that those regions are not used. Obviously that's not a guarantee, and whether it's a good idea to postpone replacement indefinitely I guess depends on context, but I've had disks that remained usable for years of casual daily use after the first failure. You just have to remember to go through the whole badblocks check whenever you reformat (which is a good idea anyway).
– goldilocks
Mar 27 '13 at 16:02
1
@goldilocks, yes they can (a student had a disk that had a half dozen bad sectors for years without problems), but they usually die after a few hours to a day (years and years of experience, both with a largeish set of department computers and assorted student machines avail that).
– vonbrand
Mar 27 '13 at 16:11
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
accepted
The usual advice is to not run fsck on a mounted file system . You get unreliable results - while fsck is trying to scan the file system, the kernel is still reading and writing data to it, so it will appear, to fsck, inconsistent. Some file systems allow online use of fsck, but not all - FreeBSD, for example, can check a static snapshot of a UFS2 file system while it is in use, but you still wouldn't check the file system itself while it's mounted.
The best way to check your file system is to unmount it, then run fsck on it. If it still reports problems, you can take remedial action.
answered Mar 27 '13 at 14:48
D_Bye
10.4k13227
add a comment |
up vote
5
down vote
accepted
The usual advice is to not run fsck on a mounted file system . You get unreliable results - while fsck is trying to scan the file system, the kernel is still reading and writing data to it, so it will appear, to fsck, inconsistent. Some file systems allow online use of fsck, but not all - FreeBSD, for example, can check a static snapshot of a UFS2 file system while it is in use, but you still wouldn't check the file system itself while it's mounted.
The best way to check your file system is to unmount it, then run fsck on it. If it still reports problems, you can take remedial action.
answered Mar 27 '13 at 14:48
D_Bye
10.4k13227
add a comment |
up vote
5
down vote
accepted
up vote
5
down vote
accepted
The usual advice is to not run fsck on a mounted file system . You get unreliable results - while fsck is trying to scan the file system, the kernel is still reading and writing data to it, so it will appear, to fsck, inconsistent. Some file systems allow online use of fsck, but not all - FreeBSD, for example, can check a static snapshot of a UFS2 file system while it is in use, but you still wouldn't check the file system itself while it's mounted.
The best way to check your file system is to unmount it, then run fsck on it. If it still reports problems, you can take remedial action.
answered Mar 27 '13 at 14:48
D_Bye
10.4k13227
The usual advice is to not run fsck on a mounted file system . You get unreliable results - while fsck is trying to scan the file system, the kernel is still reading and writing data to it, so it will appear, to fsck, inconsistent. Some file systems allow online use of fsck, but not all - FreeBSD, for example, can check a static snapshot of a UFS2 file system while it is in use, but you still wouldn't check the file system itself while it's mounted.
The best way to check your file system is to unmount it, then run fsck on it. If it still reports problems, you can take remedial action.
answered Mar 27 '13 at 14:48
D_Bye
10.4k13227
answered Mar 27 '13 at 14:48
D_Bye
10.4k13227
answered Mar 27 '13 at 14:48
D_Bye
10.4k13227
answered Mar 27 '13 at 14:48
D_Bye
10.4k13227
10.4k13227
add a comment |
add a comment |
up vote
2
down vote
If fsck(8) says a filesystem has errors (in this case, the journal could't be replayed as it was mounted read-only, for starters), it has problems. You should shut down, start in maintenance mode (add single or 1 to the kernel line when booting; or even boot with install/rescue media) and do the full fsck. Check the manual for your exact filesystem, flags to use vary. Be careful! It asks for confirmation before doing some possibly dangerous operations. Most of the time you can't do anything byt say "yes" to everything, bu read what it says/asks.
Once you get the system working, find out what messed up the filesystem. It has been literally years with ext2/3/4 that I haven't seen filesystem corruption (but I don't just pull the plug or press the Big Red Button at random either...), so it could be bad handling or failing hardware. If the disk is failing, turn the machine off and get a replacement ASAP. Failing disks usually last hours (as in "a few", not as in "some hundred") before they are gone for good. Use that time to rescue your data, later you can do the autopsy to the failing disk at leisure. If it turns out to be a false alarm, you've got yourself space for the ripped CDs ;-)
answered Mar 27 '13 at 14:57
vonbrand
14.1k22644
I am in the opposite boat. I have seen tons of filesystem corruption in ext3 over the past few years. Granted, these servers stayed very heavily I/O loaded and there was a large pool (3,500) that could potentially have a problem. Most of the time it was related to some kind of hardware failure.
– jordanm
Mar 27 '13 at 15:09
Disks which are failing due to bad blocks can last a lot longer than hours if you fix the file system on them and add the bad blocks to the filesystem list, so that those regions are not used. Obviously that's not a guarantee, and whether it's a good idea to postpone replacement indefinitely I guess depends on context, but I've had disks that remained usable for years of casual daily use after the first failure. You just have to remember to go through the whole badblocks check whenever you reformat (which is a good idea anyway).
– goldilocks
Mar 27 '13 at 16:02
1
@goldilocks, yes they can (a student had a disk that had a half dozen bad sectors for years without problems), but they usually die after a few hours to a day (years and years of experience, both with a largeish set of department computers and assorted student machines avail that).
– vonbrand
Mar 27 '13 at 16:11
add a comment |
up vote
2
down vote
If fsck(8) says a filesystem has errors (in this case, the journal could't be replayed as it was mounted read-only, for starters), it has problems. You should shut down, start in maintenance mode (add single or 1 to the kernel line when booting; or even boot with install/rescue media) and do the full fsck. Check the manual for your exact filesystem, flags to use vary. Be careful! It asks for confirmation before doing some possibly dangerous operations. Most of the time you can't do anything byt say "yes" to everything, bu read what it says/asks.
Once you get the system working, find out what messed up the filesystem. It has been literally years with ext2/3/4 that I haven't seen filesystem corruption (but I don't just pull the plug or press the Big Red Button at random either...), so it could be bad handling or failing hardware. If the disk is failing, turn the machine off and get a replacement ASAP. Failing disks usually last hours (as in "a few", not as in "some hundred") before they are gone for good. Use that time to rescue your data, later you can do the autopsy to the failing disk at leisure. If it turns out to be a false alarm, you've got yourself space for the ripped CDs ;-)
answered Mar 27 '13 at 14:57
vonbrand
14.1k22644
I am in the opposite boat. I have seen tons of filesystem corruption in ext3 over the past few years. Granted, these servers stayed very heavily I/O loaded and there was a large pool (3,500) that could potentially have a problem. Most of the time it was related to some kind of hardware failure.
– jordanm
Mar 27 '13 at 15:09
Disks which are failing due to bad blocks can last a lot longer than hours if you fix the file system on them and add the bad blocks to the filesystem list, so that those regions are not used. Obviously that's not a guarantee, and whether it's a good idea to postpone replacement indefinitely I guess depends on context, but I've had disks that remained usable for years of casual daily use after the first failure. You just have to remember to go through the whole badblocks check whenever you reformat (which is a good idea anyway).
– goldilocks
Mar 27 '13 at 16:02
1
@goldilocks, yes they can (a student had a disk that had a half dozen bad sectors for years without problems), but they usually die after a few hours to a day (years and years of experience, both with a largeish set of department computers and assorted student machines avail that).
– vonbrand
Mar 27 '13 at 16:11
add a comment |
up vote
2
down vote
up vote
2
down vote
If fsck(8) says a filesystem has errors (in this case, the journal could't be replayed as it was mounted read-only, for starters), it has problems. You should shut down, start in maintenance mode (add single or 1 to the kernel line when booting; or even boot with install/rescue media) and do the full fsck. Check the manual for your exact filesystem, flags to use vary. Be careful! It asks for confirmation before doing some possibly dangerous operations. Most of the time you can't do anything byt say "yes" to everything, bu read what it says/asks.
Once you get the system working, find out what messed up the filesystem. It has been literally years with ext2/3/4 that I haven't seen filesystem corruption (but I don't just pull the plug or press the Big Red Button at random either...), so it could be bad handling or failing hardware. If the disk is failing, turn the machine off and get a replacement ASAP. Failing disks usually last hours (as in "a few", not as in "some hundred") before they are gone for good. Use that time to rescue your data, later you can do the autopsy to the failing disk at leisure. If it turns out to be a false alarm, you've got yourself space for the ripped CDs ;-)
answered Mar 27 '13 at 14:57
vonbrand
14.1k22644
If fsck(8) says a filesystem has errors (in this case, the journal could't be replayed as it was mounted read-only, for starters), it has problems. You should shut down, start in maintenance mode (add single or 1 to the kernel line when booting; or even boot with install/rescue media) and do the full fsck. Check the manual for your exact filesystem, flags to use vary. Be careful! It asks for confirmation before doing some possibly dangerous operations. Most of the time you can't do anything byt say "yes" to everything, bu read what it says/asks.
Once you get the system working, find out what messed up the filesystem. It has been literally years with ext2/3/4 that I haven't seen filesystem corruption (but I don't just pull the plug or press the Big Red Button at random either...), so it could be bad handling or failing hardware. If the disk is failing, turn the machine off and get a replacement ASAP. Failing disks usually last hours (as in "a few", not as in "some hundred") before they are gone for good. Use that time to rescue your data, later you can do the autopsy to the failing disk at leisure. If it turns out to be a false alarm, you've got yourself space for the ripped CDs ;-)
answered Mar 27 '13 at 14:57
vonbrand
14.1k22644
answered Mar 27 '13 at 14:57
vonbrand
14.1k22644
answered Mar 27 '13 at 14:57
vonbrand
14.1k22644
answered Mar 27 '13 at 14:57
vonbrand
14.1k22644
14.1k22644
I am in the opposite boat. I have seen tons of filesystem corruption in ext3 over the past few years. Granted, these servers stayed very heavily I/O loaded and there was a large pool (3,500) that could potentially have a problem. Most of the time it was related to some kind of hardware failure.
– jordanm
Mar 27 '13 at 15:09
Disks which are failing due to bad blocks can last a lot longer than hours if you fix the file system on them and add the bad blocks to the filesystem list, so that those regions are not used. Obviously that's not a guarantee, and whether it's a good idea to postpone replacement indefinitely I guess depends on context, but I've had disks that remained usable for years of casual daily use after the first failure. You just have to remember to go through the whole badblocks check whenever you reformat (which is a good idea anyway).
– goldilocks
Mar 27 '13 at 16:02
1
@goldilocks, yes they can (a student had a disk that had a half dozen bad sectors for years without problems), but they usually die after a few hours to a day (years and years of experience, both with a largeish set of department computers and assorted student machines avail that).
– vonbrand
Mar 27 '13 at 16:11
add a comment |
I am in the opposite boat. I have seen tons of filesystem corruption in ext3 over the past few years. Granted, these servers stayed very heavily I/O loaded and there was a large pool (3,500) that could potentially have a problem. Most of the time it was related to some kind of hardware failure.
– jordanm
Mar 27 '13 at 15:09
Disks which are failing due to bad blocks can last a lot longer than hours if you fix the file system on them and add the bad blocks to the filesystem list, so that those regions are not used. Obviously that's not a guarantee, and whether it's a good idea to postpone replacement indefinitely I guess depends on context, but I've had disks that remained usable for years of casual daily use after the first failure. You just have to remember to go through the whole badblocks check whenever you reformat (which is a good idea anyway).
– goldilocks
Mar 27 '13 at 16:02
1
@goldilocks, yes they can (a student had a disk that had a half dozen bad sectors for years without problems), but they usually die after a few hours to a day (years and years of experience, both with a largeish set of department computers and assorted student machines avail that).
– vonbrand
Mar 27 '13 at 16:11
I am in the opposite boat. I have seen tons of filesystem corruption in ext3 over the past few years. Granted, these servers stayed very heavily I/O loaded and there was a large pool (3,500) that could potentially have a problem. Most of the time it was related to some kind of hardware failure.
– jordanm
Mar 27 '13 at 15:09
I am in the opposite boat. I have seen tons of filesystem corruption in ext3 over the past few years. Granted, these servers stayed very heavily I/O loaded and there was a large pool (3,500) that could potentially have a problem. Most of the time it was related to some kind of hardware failure.
– jordanm
Mar 27 '13 at 15:09
Disks which are failing due to bad blocks can last a lot longer than hours if you fix the file system on them and add the bad blocks to the filesystem list, so that those regions are not used. Obviously that's not a guarantee, and whether it's a good idea to postpone replacement indefinitely I guess depends on context, but I've had disks that remained usable for years of casual daily use after the first failure. You just have to remember to go through the whole badblocks check whenever you reformat (which is a good idea anyway).
– goldilocks
Mar 27 '13 at 16:02
Disks which are failing due to bad blocks can last a lot longer than hours if you fix the file system on them and add the bad blocks to the filesystem list, so that those regions are not used. Obviously that's not a guarantee, and whether it's a good idea to postpone replacement indefinitely I guess depends on context, but I've had disks that remained usable for years of casual daily use after the first failure. You just have to remember to go through the whole badblocks check whenever you reformat (which is a good idea anyway).
– goldilocks
Mar 27 '13 at 16:02
1
1
@goldilocks, yes they can (a student had a disk that had a half dozen bad sectors for years without problems), but they usually die after a few hours to a day (years and years of experience, both with a largeish set of department computers and assorted student machines avail that).
– vonbrand
Mar 27 '13 at 16:11
@goldilocks, yes they can (a student had a disk that had a half dozen bad sectors for years without problems), but they usually die after a few hours to a day (years and years of experience, both with a largeish set of department computers and assorted student machines avail that).
– vonbrand
Mar 27 '13 at 16:11
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f69332%2fif-fsck-n-path-says-errors-then-its-100-true-that-the-fs-has-errors%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Check
tune2fs -l /dev/vgname/lvname | grep 'Filesystem state:'– jordanm
Mar 27 '13 at 14:12
I updated the q
– gasko peter
Mar 27 '13 at 14:27
You don't fsck a filesystem while it's mounted. Not even if it's mounted read-only.
– frostschutz
Mar 27 '13 at 14:48
@frostschutz
fsck -non filesystems that support it is fine on aromounted filesystem.– jordanm
Mar 27 '13 at 14:51
1
You're using LVM, so at minimum, take a snapshot and fsck that. Then there will not be concurrent writes, and you can allow journal recovery.
– derobert
Mar 27 '13 at 15:58