[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-xfs
Subject: Fwd: xfs - fixing wrong xfs size
From: Nebojsa Trpkovic <trx.lists () gmail ! com>
Date: 2009-04-13 16:33:55
Message-ID: dbd747120904130933i6ae66aedt7912a47b7e561f76 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Apr 13, 2009 at 5:02 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
> Nebojsa Trpkovic wrote:
> > hello.
> >
> > I had problem with raid5 on my system.
> > after recovering of the array, I can not mount XFS that resides on it.
> > I've run xfs_check and xfs_repair (which fixed some errors) and now I
> > can run them all day long without any errors.
> >
> > but, when I try to mount that partition, I get:
> >
> > mount: /dev/md0: can't read superblock
> >
> >
> > and there's
> >
> > Filesystem "md0": Disabling barriers, not supported by the underlying
> device
> >
> > attempt to access beyond end of device
> > md0: rw=0, want=123024384, limit=123023488
> > I/O error in filesystem ("md0") meta-data dev md0 block 0x75533f8
>
> ("xfs_read_buf") error 5 buf count 4096
> >
> > XFS: size check 2 failed
>
> So, the superblock says that the fs is 896 1k-blocks longer than the
> device actually is.
>
> > in the dmesg.
> >
> >
> > is there any way to "fix" this wrong size of XFS ?
>
> hard to say, almost certainly sounds like an md problem; is there a
> chance that your raid recovery led to a device which is somehow smaller
> than it started? You could change the superblock block-count value, but
> I'm guessing that something else has gone wrong.
>
> It might be useful to know what errors xfs_repair found.
>
> -Eric
>
thx for quick reply.
yes, I definitely had md problem - my raid5 made of 6 drives connected to
ICH9R and 2 drives connected to the masterpeace of hardware called JMicron
fell apart when later one just stopped working out of nowhere. after reboot,
JMicron worked well, but raid was out of sync with 2 members failed. I've
zeroed superblocks of raid partitions and created new one with
"assume-clear". partition tables stayed intact - I had no need to change
anything in them. that worked fine with /dev/md1 wich had reiserfs: after
long and slow reiserfs --rebuild-tree I'm able to access all files on that
partition. unforutuately, I have no way to mount xfs partition although
xfs_check and xfs_repair give no errors (I had to run xfs_repair -L /dev/md0
to get in this error-free situation).
how can I set superblock block-count value (now I have realy nothing to
loose - the only other option is to give up of that data) ?
[Attachment #5 (text/html)]
<div class="gmail_quote"><div><div></div><div class="h5"><div class="gmail_quote">On \
Mon, Apr 13, 2009 at 5:02 PM, Eric Sandeen <span dir="ltr"><<a \
href="mailto:sandeen@sandeen.net" target="_blank">sandeen@sandeen.net</a>></span> \
wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div>Nebojsa Trpkovic \
wrote:<br> > hello.<br>
><br>
> I had problem with raid5 on my system.<br>
> after recovering of the array, I can not mount XFS that resides on it.<br>
> I've run xfs_check and xfs_repair (which fixed some errors) and now I<br>
> can run them all day long without any errors.<br>
><br>
> but, when I try to mount that partition, I get:<br>
><br>
> mount: /dev/md0: can't read superblock<br>
><br>
><br>
> and there's<br>
><br>
> Filesystem "md0": Disabling barriers, not supported by the underlying \
device<br> ><br>
> attempt to access beyond end of device<br>
> md0: rw=0, want=123024384, limit=123023488<br>
> I/O error in filesystem ("md0") meta-data dev md0 block 0x75533f8<br>
<br>
("xfs_read_buf") error 5 buf count 4096<br>
><br>
> XFS: size check 2 failed<br>
<br>
</div>So, the superblock says that the fs is 896 1k-blocks longer than the<br>
device actually is.<br>
<div><br>
> in the dmesg.<br>
><br>
><br>
> is there any way to "fix" this wrong size of XFS ?<br>
<br>
</div>hard to say, almost certainly sounds like an md problem; is there a<br>
chance that your raid recovery led to a device which is somehow smaller<br>
than it started? You could change the superblock block-count value, but<br>
I'm guessing that something else has gone wrong.<br>
<br>
It might be useful to know what errors xfs_repair found.<br>
<font color="#888888"><br>
-Eric<br>
</font></blockquote></div><br><br></div></div>thx for quick reply.<br><br>yes, I \
definitely had md problem - my raid5 made of 6 drives connected to ICH9R and 2 drives \
connected to the masterpeace of hardware called JMicron fell apart when later one \
just stopped working out of nowhere. after reboot, JMicron worked well, but raid was \
out of sync with 2 members failed. I've zeroed superblocks of raid partitions and \
created new one with "assume-clear". partition tables stayed intact - I had \
no need to change anything in them. that worked fine with /dev/md1 wich had reiserfs: \
after long and slow reiserfs --rebuild-tree I'm able to access all files on that \
partition. unforutuately, I have no way to mount xfs partition although xfs_check and \
xfs_repair give no errors (I had to run xfs_repair -L /dev/md0 to get in this \
error-free situation). <br>
<br>how can I set superblock block-count value (now I have realy nothing to loose - \
the only other option is to give up of that data) ?<br><br><br> </div><br>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic