Eric Sandeen writes:
> Odd, as far as I know, growfs just uses ioctl(fd, BLKGETSIZE64, &size);
> to get the size of the underlying device, in xfsprogs/libxfs/linux.c
That's what I got from an strace as well, so I really didn't
understand it. Nonetheless, lvdisplay did return the correct size. Do
you think that it might just be an error in LVM2?
> This really shouldn't have anything to do with remounting the
> filesystem...
That's what I really thought, but in a desperate attempt, I tried it,
and since it worked, I guess that it flushed some data that made it
work.
> what exactly was the error that you saw before the remount?
With -d, it listed the same info as from xfs_info and then said "data
size unchanged, skipping". If I tried to manually specify a new size
with -D, it would list the info again and then say "data size xxx too
large, maximum is xxx (I dont't remember the exact number, but I guess
it's not really important, in any case it was the current data
size)". So it seems it really does get the old size reported back to
it.
Fredrik Tolf
> On Mon, 22 Dec 2003, Fredrik Tolf wrote:
>
> > Hi!
> >
> > I recently extended a logical volume that I have XFS on, and for some
> > reason, xfs_growfs wouldn't detect the new blocks until I had umounted
> > the filesystem and then remounted it (which, naturally, isn't really
> > desirable).
> >
> > I'm using the Sistina LVM2 and XFS that come with the stock
> > 2.6.0-test10 kernel. Is this a known issue, or did I do something
> > wrong, mayhap?
> >
> > Fredrik Tolf
> >
> >
|