xfs I/O error

xfs I/O error

[Rekrutacja119]

hello, is there any way to force XFS to ignore I/O errors? it seems it is
shutting down the fs when it encounters any error.
The problem is that i can't mark badsectors, as XFS doesn't support bad
sector marking, but i also cannot access any correct data on partition,
because when i try to access damaged sector, the whole fs goes down.

any idea why?

i use xfsprogs 2.9.4, my xfs is array made from 3 HDs, RAID 0, and one of
them is getting some bad sectors. i cannot replace it currently.

after i run xfs_repair on it, i was able to mount it and access the data,
but when somebody tries to access bad data, the whole XFS goes down. i don't
want that, i also dont have place to xfsmetadump the whole array to another
disks.

i tried scaning whole disk with badblocks (badblocks -c 1 -s -v /dev/sdb),
and then running dd if=/dev/zero of=/dev/sdb count=1 bs=1
seek=NUMBER_FROM_BADBLOCKOUTPUT

but every block was written fine! (which is strange i guess), and it didnt
help.

please advise me anything other than switching the drive (i will do it,
can't now though) or dumping the whole thing as i need to much space.

the easiest solution would be to just ignore errors, and if not, then to
somehow force xfs to mark them as bad sectors (smartctl is showing errors
like for example

# 2  Extended offline    Completed: unknown failure    90%      9395
-

or


Error 8324 occurred at disk power-on lifetime: 9398 hours (391 days + 14
hours)
  When the command that caused the error occurred, the device was active or
idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 30 33 59 e6  Error: UNC at LBA = 0x06593330 = 106509104


[[HTML alternate version deleted]]

Re: xfs I/O error

[Iustin Pop]

On Sat, Feb 23, 2008 at 10:46:52PM +0100, Rekrutacja119 wrote:
> hello, is there any way to force XFS to ignore I/O errors? it seems it is
> shutting down the fs when it encounters any error.
> The problem is that i can't mark badsectors, as XFS doesn't support bad
> sector marking, but i also cannot access any correct data on partition,
> because when i try to access damaged sector, the whole fs goes down.
> 
> any idea why?
> 
> i use xfsprogs 2.9.4, my xfs is array made from 3 HDs, RAID 0, and one of
> them is getting some bad sectors. i cannot replace it currently.
> 
> after i run xfs_repair on it, i was able to mount it and access the data,
> but when somebody tries to access bad data, the whole XFS goes down. i don't
> want that, i also dont have place to xfsmetadump the whole array to another
> disks.
> 
> i tried scaning whole disk with badblocks (badblocks -c 1 -s -v /dev/sdb),
> and then running dd if=/dev/zero of=/dev/sdb count=1 bs=1
> seek=NUMBER_FROM_BADBLOCKOUTPUT
> 
> but every block was written fine! (which is strange i guess), and it didnt
> help.

I'm not really sure, but the above seems wrong. badblocks has a default
block size of 1024 (-c does something else, not set the block size), and
you use that block number as an offset in bytes for dd  (because you set
bs=1).

I would recommend to try the dd again, but with bs=1024. And afterwards,
rerun badblocks and check you have no errors.

As for xfs, I don't think if it can do what you want (ignore bad
blocks), if the error is in the metadata sections.

regards,
iustin

Re: xfs I/O error

[Rekrutacja119]

so i should use the list i got from badblocks with dd but with bs=1024? are
you sure? i'm not sure what is my block size, but xfs_info says this:

debian:/# xfs_info /dev/md0
meta-data=/dev/md0               isize=256    agcount=32, agsize=5723342
blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=183146912, imaxpct=25
         =                       sunit=2      swidth=6 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=32768, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=24576  blocks=0, rtextents=0

i think i made it with 4K stack size ... well anyways, i should use the list
i got earlier and just try dd but with bs=1024... ? don't want to erase more
than i have to. (i want to do it so i can smartctl -t offline /dev/sdb then,
so maybe it will somehow see that these blocks are broken and mark them)


2008/2/23, Iustin Pop <iusty@k1024.org>:
>
> On Sat, Feb 23, 2008 at 10:46:52PM +0100, Rekrutacja119 wrote:
> > hello, is there any way to force XFS to ignore I/O errors? it seems it
> is
> > shutting down the fs when it encounters any error.
> > The problem is that i can't mark badsectors, as XFS doesn't support bad
> > sector marking, but i also cannot access any correct data on partition,
> > because when i try to access damaged sector, the whole fs goes down.
> >
> > any idea why?
> >
> > i use xfsprogs 2.9.4, my xfs is array made from 3 HDs, RAID 0, and one
> of
> > them is getting some bad sectors. i cannot replace it currently.
> >
> > after i run xfs_repair on it, i was able to mount it and access the
> data,
> > but when somebody tries to access bad data, the whole XFS goes down. i
> don't
> > want that, i also dont have place to xfsmetadump the whole array to
> another
> > disks.
> >
> > i tried scaning whole disk with badblocks (badblocks -c 1 -s -v
> /dev/sdb),
> > and then running dd if=/dev/zero of=/dev/sdb count=1 bs=1
> > seek=NUMBER_FROM_BADBLOCKOUTPUT
> >
> > but every block was written fine! (which is strange i guess), and it
> didnt
> > help.
>
> I'm not really sure, but the above seems wrong. badblocks has a default
> block size of 1024 (-c does something else, not set the block size), and
> you use that block number as an offset in bytes for dd  (because you set
> bs=1).
>
> I would recommend to try the dd again, but with bs=1024. And afterwards,
> rerun badblocks and check you have no errors.
>
> As for xfs, I don't think if it can do what you want (ignore bad
> blocks), if the error is in the metadata sections.
>
> regards,
> iustin
>


[[HTML alternate version deleted]]

Re: xfs I/O error

[Eric Sandeen]

Rekrutacja119 wrote:
> hello, is there any way to force XFS to ignore I/O errors? it seems it is
> shutting down the fs when it encounters any error.

It does not shut down on any error; it should only be shutting down on
errors after which it cannot guarantee filesystem consistency.

> The problem is that i can't mark badsectors, as XFS doesn't support bad
> sector marking, but i also cannot access any correct data on partition,
> because when i try to access damaged sector, the whole fs goes down.
>
> any idea why?

Depends on what the sector is and what xfs is doing with it.

(btw the trace you posted in your next messages looks like you edited
out some relevant information)

> i use xfsprogs 2.9.4, my xfs is array made from 3 HDs, RAID 0, and one of
> them is getting some bad sectors. i cannot replace it currently.

xfs can't really help you with your bad hardware ;)

> after i run xfs_repair on it, i was able to mount it and access the data,
> but when somebody tries to access bad data, the whole XFS goes down. i don't
> want that, i also dont have place to xfsmetadump the whole array to another
> disks.

I do not think metadump does what you think it does... it only copies
metadata.

> i tried scaning whole disk with badblocks (badblocks -c 1 -s -v /dev/sdb),
> and then running dd if=/dev/zero of=/dev/sdb count=1 bs=1
> seek=NUMBER_FROM_BADBLOCKOUTPUT
> 
> but every block was written fine! (which is strange i guess), and it didnt
> help.

as iustin said, I think you just pretty well clobbered some important
metadata on your disk.  badblocks gives you block numbers in 1024 units.
 You gave dd a block size of 1... then rather than seeking out the
proper number of 1024 units, you seeked that many bytes; overwriting
probably important stuff at the beginning of your disk (since your wrote
at 1/1024 the offset that you should have)

> please advise me anything other than switching the drive (i will do it,
> can't now though) or dumping the whole thing as i need to much space.

mount it readonly to get to the data you need?

> the easiest solution would be to just ignore errors, and if not, then to
> somehow force xfs to mark them as bad sectors (smartctl is showing errors
> like for example

IMHO marking sectors bad is pointless.  If you have a failing drive, it
will only get worse.  At best you could use badblocks to try some writes
to remap; assuming you don't get it wrong and just zero out more of your
disk...

-Eric

> # 2  Extended offline    Completed: unknown failure    90%      9395
> -
> 
> or
> 
> 
> Error 8324 occurred at disk power-on lifetime: 9398 hours (391 days + 14
> hours)
>   When the command that caused the error occurred, the device was active or
> idle.
> 
>   After command completion occurred, registers were:
>   ER ST SC SN CL CH DH
>   -- -- -- -- -- -- --
>   40 51 00 30 33 59 e6  Error: UNC at LBA = 0x06593330 = 106509104
> 
> 
> [[HTML alternate version deleted]]
> 
> 

Re: xfs I/O error

[Iustin Pop]

On Sat, Feb 23, 2008 at 11:14:32PM +0100, Rekrutacja119 wrote:
> so i should use the list i got from badblocks with dd but with bs=1024? are
> you sure? i'm not sure what is my block size, but xfs_info says this:
the block size of the filesystem has no relation to the block size
badblocks uses in checking the block device.
> 
[...]
> 
> i think i made it with 4K stack size ... well anyways, i should use the list
> i got earlier and just try dd but with bs=1024... ? don't want to erase more
> than i have to. (i want to do it so i can smartctl -t offline /dev/sdb then,
> so maybe it will somehow see that these blocks are broken and mark them)

I don't understand what do you want to do with smartctl at all. How
would offlining the disk would help?

Again, I would:
  - take the block list given by badblocks
  - verify that each block can't be read  first via dd if=/dev/...
    of=/dev/null bs=1024 count=1 seek=NUMBER_FROM_BADBLOCK
  - if confirmed that you got the right 'bad' blocks, use that for dd
    with bs=1024 to write zeroes over them

As Eric confirmed, you probably already destroyed some good data on the
drive.

regards,
iustin

Re: xfs I/O error

[Rekrutacja119]

smartctl -t offline is i think scheduling a SMART test

i will try what you say, but there is no way to force XFS to not unmount
filesystem if it finds out I/O error?

also, i didnt edit any info, it was just all i got from messages log

2008/2/24, Iustin Pop <iusty@k1024.org>:
>
> On Sat, Feb 23, 2008 at 11:14:32PM +0100, Rekrutacja119 wrote:
> > so i should use the list i got from badblocks with dd but with bs=1024?
> are
> > you sure? i'm not sure what is my block size, but xfs_info says this:
>
> the block size of the filesystem has no relation to the block size
> badblocks uses in checking the block device.
> >
> [...]
>
> >
> > i think i made it with 4K stack size ... well anyways, i should use the
> list
> > i got earlier and just try dd but with bs=1024... ? don't want to erase
> more
> > than i have to. (i want to do it so i can smartctl -t offline /dev/sdb
> then,
> > so maybe it will somehow see that these blocks are broken and mark them)
>
>
> I don't understand what do you want to do with smartctl at all. How
> would offlining the disk would help?
>
> Again, I would:
>   - take the block list given by badblocks
>   - verify that each block can't be read  first via dd if=/dev/...
>     of=/dev/null bs=1024 count=1 seek=NUMBER_FROM_BADBLOCK
>   - if confirmed that you got the right 'bad' blocks, use that for dd
>     with bs=1024 to write zeroes over them
>
> As Eric confirmed, you probably already destroyed some good data on the
> drive.
>
> regards,
>
> iustin
>


[[HTML alternate version deleted]]

Re: xfs I/O error

[Ragnar Kjørstad]

On Sat, Feb 23, 2008 at 10:46:52PM +0100, Rekrutacja119 wrote:
> the easiest solution would be to just ignore errors, and if not, then to
> somehow force xfs to mark them as bad sectors

If you really wanted to you could probably use dm to map your bad
sectors to another device.

-- 
Ragnar Kjørstad
Software Engineer
Platform Computing

Re: xfs I/O error

[Iustin Pop]

On Sun, Feb 24, 2008 at 12:52:38PM +0100, Rekrutacja119 wrote:
> smartctl -t offline is i think scheduling a SMART test
ah yes, you're right, I'm sorry.

I would recommend to use not -t offline but -t long - AFAIK, the
'offline' test just updates the attributes but not scan the whole of the
disk.

In any case, I don't think a smart test is better than badblocks...

regards,
iustin

Re: xfs I/O error

[Rekrutacja119]

i tried doing dd if with the bs=1024, and the dd command went fine! i really
don't understand it :( i wont write zeros to it, if it is fine, since this
sector is probably correct.

any ideas what to do now?

also - still no solution to force XFS to not shutdown itself?


2008/2/24, Iustin Pop <iusty@k1024.org>:
>
> On Sun, Feb 24, 2008 at 12:52:38PM +0100, Rekrutacja119 wrote:
> > smartctl -t offline is i think scheduling a SMART test
> ah yes, you're right, I'm sorry.
>
> I would recommend to use not -t offline but -t long - AFAIK, the
> 'offline' test just updates the attributes but not scan the whole of the
> disk.
>
> In any case, I don't think a smart test is better than badblocks...
>
> regards,
> iustin
>


[[HTML alternate version deleted]]

Re: xfs I/O error

[Eric Sandeen]

Rekrutacja119 wrote:
> i tried doing dd if with the bs=1024, and the dd command went fine! i really
> don't understand it :( i wont write zeros to it, if it is fine, since this
> sector is probably correct.
> 
> any ideas what to do now?
> 
> also - still no solution to force XFS to not shutdown itself?

mount it readonly.

xfs isn't going to continue if doing so would further corrupt the fs.

-Eric

Re: xfs I/O error

[Rekrutacja119]

2008/2/25, Ragnar Kjørstad <xfs@ragnark.vestdata.no>:
>
> On Mon, Feb 25, 2008 at 05:47:12PM +0100, Rekrutacja119 wrote:
> > 2008/2/24, Ragnar Kjørstad <xfs@ragnark.vestdata.no>:
> > >
> > > On Sat, Feb 23, 2008 at 10:46:52PM +0100, Rekrutacja119 wrote:
> > > > the easiest solution would be to just ignore errors, and if not,
> then to
> > > > somehow force xfs to mark them as bad sectors
> > >
> > > If you really wanted to you could probably use dm to map your bad
> > > sectors to another device.
> >
> > what do you mean by that? how to do it ?
>
> dm is the linux device mapper. It is used by LVM to map virtual blocks
> from logical volumes to physical blocks on logical volumes, but you can
> also create your custom remapping table to do other things.
>
> I don't know the exact dmsetup command, but you should be able to find
> that in the dm documentation or ask on the dm mailinglist.
>
> http://sources.redhat.com/dm/



but i suppose i can do it like Eric told me - mount it read only. effects
would be the same - i will have acess to everything that is readable, and i
wont even have to copy all the stuff into the same device (i can copy half
of the dirs to one, and other half to others)

the read-only advice was very good and thank you very much eric, it helped
me a lot.


[[HTML alternate version deleted]]

xfs i/O error

[rnb]

Running Ubuntu 9.04 kernel 2.26.28.14 generic
Drive mounts fine.
xfs_repair shows no errors
sudo xfs_repair /dev/sdg1
 Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

xfs_check did move a few things around but finished fine

sudo xfs_fsr -v /dev/sdg1 <== This is just so far it is still running.
/media/Films start inode=0
ino=140
bad read of 0 bytes from ino=140: Input/output error
ino=139
extents before:66 after:8      ino=139
ino=145
extents before:42 after:7      ino=145
ino=146
extents before:40 after:8      ino=146
ino=143
bad read of 0 bytes from ino=143: Input/output error
ino=144
extents before:27 after:8      ino=144
ino=8763008
bad read of 0 bytes from ino=8763008: Input/output error
ino=8763059
bad read of 0 bytes from ino=8763059: Input/output error
ino=8763057
extents before:307 after:12      ino=8763057
ino=8763058
extents before:259 after:11      ino=8763058
ino=8763024
bad read of 0 bytes from ino=8763024: Input/output error
ino=8763055
kk
extents before:125 after:10      ino=8763055
ino=8763030
bad read of 0 bytes from ino=8763030: Input/output error
ino=8763060
bad read of 0 bytes from ino=8763060: Input/output error
ino=8763056
extents before:62 after:13      ino=8763056
ino=8763066

Now my issue is how do I fix it if xfs_repair doesn't see a problem.
Anything getting copied to the drive works fine in place wasn't until i
tried to move it off I noticed the issue. Some things copy fine from it
several others fail. Then i get Input/output error. It is a full 1tb drive .
WD mybook it lost power which I think is what caused this issue. How can I
correct the issue. Everything I try takes a hell of a long time and doesn't
yield a positive result
-- 
View this message in context: http://www.nabble.com/xfs-i-O-error-tp24742623p24742623.html
Sent from the Xfs - General mailing list archive at Nabble.com.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs i/O error

[Eric Sandeen]

rnb wrote:
> Running Ubuntu 9.04 kernel 2.26.28.14 generic
> Drive mounts fine.
> xfs_repair shows no errors
...

> 
> xfs_check did move a few things around but finished fine

Actually xfs_check never changes anything ;)

> sudo xfs_fsr -v /dev/sdg1 <== This is just so far it is still running.
> /media/Films start inode=0
> ino=140
> bad read of 0 bytes from ino=140: Input/output error

Anything in dmesg when this happens?

...

> Now my issue is how do I fix it if xfs_repair doesn't see a problem.

It must not be a problem on-disk.  At least, hopefully not.  :)

> Anything getting copied to the drive works fine in place wasn't until i
> tried to move it off I noticed the issue. Some things copy fine from it
> several others fail. Then i get Input/output error. It is a full 1tb drive .
> WD mybook it lost power which I think is what caused this issue. How can I
> correct the issue. Everything I try takes a hell of a long time and doesn't
> yield a positive result

Oh, so it's not just fsr that does it?  cp too?

Anyway, look at dmesg when you get the error and see if there are
messages logged from the kernel when this happens.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs i/O error

[rnb]

[70273.864305] sd 8:0:0:0: [sdg] Sense Key : Medium Error [current] 
[70273.864314] Info fld=0x0
[70273.864318] sd 8:0:0:0: [sdg] Add. Sense: Unrecovered read error
[70273.864327] end_request: I/O error, dev sdg, sector 378206415
[70276.938405] sd 8:0:0:0: [sdg] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE,SUGGEST_OK

running a defrag that last few hours so there are tonnes of those. Like i
said it has no issues mounting, xfs_repair fails to see the problem. Bad
sectors I hope not the drives are a few months old and this is a storage
server to it isn't like it is getting a tonne of writing done to it. Being
external though I can't rule out hardware failure and smartctl doesn't run
over USB.

rnb wrote:
> 
> Running Ubuntu 9.04 kernel 2.26.28.14 generic
> Drive mounts fine.
> xfs_repair shows no errors
> sudo xfs_repair /dev/sdg1
>  Phase 1 - find and verify superblock...
> Phase 2 - using internal log
>         - zero log...
>         - scan filesystem freespace and inode maps...
>         - found root inode chunk
> Phase 3 - for each AG...
>         - scan and clear agi unlinked lists...
>         - process known inodes and perform inode discovery...
>         - agno = 0
>         - agno = 1
>         - agno = 2
>         - agno = 3
>         - process newly discovered inodes...
> Phase 4 - check for duplicate blocks...
>         - setting up duplicate extent list...
>         - check for inodes claiming duplicate blocks...
>         - agno = 0
>         - agno = 1
>         - agno = 2
>         - agno = 3
> Phase 5 - rebuild AG headers and trees...
>         - reset superblock...
> Phase 6 - check inode connectivity...
>         - resetting contents of realtime bitmap and summary inodes
>         - traversing filesystem ...
>         - traversal finished ...
>         - moving disconnected inodes to lost+found ...
> Phase 7 - verify and correct link counts...
> done
> 
> xfs_check did move a few things around but finished fine
> 
> sudo xfs_fsr -v /dev/sdg1 <== This is just so far it is still running.
> /media/Films start inode=0
> ino=140
> bad read of 0 bytes from ino=140: Input/output error
> ino=139
> extents before:66 after:8      ino=139
> ino=145
> extents before:42 after:7      ino=145
> ino=146
> extents before:40 after:8      ino=146
> ino=143
> bad read of 0 bytes from ino=143: Input/output error
> ino=144
> extents before:27 after:8      ino=144
> ino=8763008
> bad read of 0 bytes from ino=8763008: Input/output error
> ino=8763059
> bad read of 0 bytes from ino=8763059: Input/output error
> ino=8763057
> extents before:307 after:12      ino=8763057
> ino=8763058
> extents before:259 after:11      ino=8763058
> ino=8763024
> bad read of 0 bytes from ino=8763024: Input/output error
> ino=8763055
> kk
> extents before:125 after:10      ino=8763055
> ino=8763030
> bad read of 0 bytes from ino=8763030: Input/output error
> ino=8763060
> bad read of 0 bytes from ino=8763060: Input/output error
> ino=8763056
> extents before:62 after:13      ino=8763056
> ino=8763066
> 
> Now my issue is how do I fix it if xfs_repair doesn't see a problem.
> Anything getting copied to the drive works fine in place wasn't until i
> tried to move it off I noticed the issue. Some things copy fine from it
> several others fail. Then i get Input/output error. It is a full 1tb drive
> . WD mybook it lost power which I think is what caused this issue. How can
> I correct the issue. Everything I try takes a hell of a long time and
> doesn't yield a positive result
> 

-- 
View this message in context: http://www.nabble.com/xfs-i-O-error-tp24742623p24747808.html
Sent from the Xfs - General mailing list archive at Nabble.com.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs i/O error

[Michael Monnerie]

[-- Attachment #1.1: Type: text/plain, Size: 666 bytes --]

On Donnerstag 30 Juli 2009 rnb wrote:
> [70273.864305] sd 8:0:0:0: [sdg] Sense Key : Medium Error [current]
> [70273.864314] Info fld=0x0
> [70273.864318] sd 8:0:0:0: [sdg] Add. Sense: Unrecovered read error
> [70273.864327] end_request: I/O error, dev sdg, sector 378206415

Disk is bad, replace it.

mfg zmi
-- 
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4


[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs i/O error

[Eric Sandeen]

Michael Monnerie wrote:
> On Donnerstag 30 Juli 2009 rnb wrote:
>> [70273.864305] sd 8:0:0:0: [sdg] Sense Key : Medium Error [current]
>> [70273.864314] Info fld=0x0
>> [70273.864318] sd 8:0:0:0: [sdg] Add. Sense: Unrecovered read error
>> [70273.864327] end_request: I/O error, dev sdg, sector 378206415
> 
> Disk is bad, replace it.
> 
> mfg zmi

More or less, yep.

Read errors can be somewhat recoverable, if you write to that sector it
will remap if it can.

But anyway yeah, it's not an xfs I/O error, it's a disk IO error, and
xfs is bringing you the bad news.

repair may not have seen it because repair only looks at metadata, bad
sectors may be data in blocks, found when you try to copy data around.

-eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs i/O error

[Michael Monnerie]

[-- Attachment #1.1: Type: text/plain, Size: 774 bytes --]

On Freitag 31 Juli 2009 Eric Sandeen wrote:
> Read errors can be somewhat recoverable, if you write to that sector
> it will remap if it can.

Yes, but I've never seen a disk who did not get other broken sectors 
later. When a disk starts to get bad sectors, others will come, just 
like a virus. Therefore: you get a bad sector -> replace disk. That's by 
far less pain and cheaper than the other scenario.

mfg zmi
-- 
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4


[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs i/O error

[Emmanuel Florac]

Le Thu, 30 Jul 2009 14:45:12 -0700 (PDT) vous écriviez:

> said it has no issues mounting, xfs_repair fails to see the problem.
> Bad sectors I hope not 

Hope lost. All these messages are absolutely clear, your drive is
almost certainly dying.

-- 
--------------------------------------------------
Emmanuel Florac               www.intellique.com   
--------------------------------------------------

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs