xfs
[Top] [All Lists]

Re: Repairing a possibly incomplete xfs_growfs command?

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: Repairing a possibly incomplete xfs_growfs command?
From: Nathan Scott <nscott@xxxxxxxxxx>
Date: Fri, 18 Jan 2008 09:47:34 +1100
Cc: Mark Magpayo <mmagpayo@xxxxxxxxxxxxx>, David Chinner <dgc@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <478FD48F.1060707@sandeen.net>
Organization: Aconex
References: <9CE70E6ED2C2F64FB5537A2973FA4F02535951@pvn-3001.purevideo.local> <478FA832.7030200@sandeen.net> <9CE70E6ED2C2F64FB5537A2973FA4F02535954@pvn-3001.purevideo.local> <478FD48F.1060707@sandeen.net>
Reply-to: nscott@xxxxxxxxxx
Sender: xfs-bounce@xxxxxxxxxxx
On Thu, 2008-01-17 at 16:19 -0600, Eric Sandeen wrote:
> 
> Yep, in 1k units, so:
> 
> 19046932480*1024
> 19504058859520
> 
> and:
> 
> superblock read failed, offset 19504058859520, size 2048, ag 64, rval
> 0
> 
> so it's trying to read a 2k (?) superblock right in the last 1k of the
> device?  Hrm.  (Dave, Barry - isn't that 2048 the sector size, not
> block
> size?)
> 
> Also from your sb 0 printout:
> 
> blocksize = 4096
> dblocks = 11904332800

sectsize = 512
sectlog = 9

So, SB reckons its a regular 512 byte sector size.  Perhaps the device
driver is reporting a 2K sector size from the BLKSSZGET ioctl?  That'd
be wierd, cos mkfs would have issued a warning when creating with 512
byte sectors.  *shrug*.

> is 48760147148800, exactly 2.5x bigger than your device is. Weird.

cheers.

-- 
Nathan


<Prev in Thread] Current Thread [Next in Thread>