All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Nick Bowler <nbowler@draconx.ca>
Cc: linux-xfs@vger.kernel.org
Subject: Re: Enlarging w/ xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Inappropriate ioctl for device
Date: Mon, 10 Dec 2018 09:33:46 -0500	[thread overview]
Message-ID: <20181210143345.GB8356@bfoster> (raw)
In-Reply-To: <20181210042842.GA16286@draconx.ca>

On Sun, Dec 09, 2018 at 11:29:04PM -0500, Nick Bowler wrote:
> Hello,
> 
> I'm a bit new to using XFS and I ran into some errors trying to enlarge
> a filesystem.  This setup uses dmcrypt on top of md raid and I just
> reshaped the array to add additional storage.  The underlying block
> device reflects the new size, but the filesystem hasn't been enlarged
> yet:
> 
>   # blockdev --report /dev/mapper/data             
>   RO    RA   SSZ   BSZ   StartSec            Size   Device
>   rw  4096   512  4096          0  20001386921984   /dev/mapper/data
> 
>   # findmnt /dev/mapper/data
>   TARGET    SOURCE           FSTYPE OPTIONS
>   /mnt/data /dev/mapper/data xfs    rw,relatime,attr2,inode64,sunit=1024,swidth=2048,noquota
> 
>   # df -h /mnt/data
>   Filesystem        Size  Used Avail Use% Mounted on
>   /dev/mapper/data  9.1T  8.5T  649G  94% /mnt/data
> 
> So I read the manpage and it seems all I should need to do is run
> xfs_growfs on the mounted filesystem but...
> 
>   # xfs_growfs /mnt/data
>   meta-data=/dev/mapper/data       isize=512    agcount=32, agsize=76299136 blks
>            =                       sectsz=4096  attr=2, projid32bit=1
>            =                       crc=1        finobt=1, sparse=1, rmapbt=0
>            =                       reflink=0
>   data     =                       bsize=4096   blocks=2441572352, imaxpct=5
>            =                       sunit=128    swidth=256 blks
>   naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
>   log      =internal log           bsize=4096   blocks=521728, version=2
>            =                       sectsz=4096  sunit=1 blks, lazy-count=1
>   realtime =none                   extsz=4096   blocks=0, rtextents=0
>   xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Inappropriate ioctl for device
>   xfs_growfs: XFS_IOC_FSGEOMETRY xfsctl failed: Inappropriate ioctl for device
> 
> ... and the filesystem is not enlarged.  Looking at strace output, the
> failing ioctls seem to be:
> 
>   openat(AT_FDCWD, "/mnt/data", O_RDONLY) = 3
>   [...]
>   ioctl(3, _IOC(_IOC_WRITE, 0x58, 0x6e, 0x10), 0xffcc9a80) = -1 ENOTTY (Inappropriate ioctl for device)
>   [...]
>   ioctl(3, _IOC(_IOC_READ, 0x58, 0x64, 0x70), 0xffcc9ba0) = -1 ENOTTY (Inappropriate ioctl for device)
> 
> Kernel version is 4.14.82 with xfsprogs 4.17.0, although I tried also
> with xfsprogs 4.19.0 and received the same errors.
> 
> Am I missing something obvious here?  What further steps should I take
> to help solve this?
> 

The only thing that comes to mind while poking through the code is
perhaps xfsprogs is sending the traditional XFS_IOC_GROWFSDATA command
into the compat_ioctl() path somehow or another (assuming
BROKEN_X86_ALIGNMENT is set).

What arch is your kernel/xfsprogs? What does 'cat
/sys/kernel/debug/trace/trace' show if you run  'trace-cmd start -e
xfs:xfs_file*ioctl*' and then attempt the growfs?

Brian

> Thanks,
>   Nick

  reply	other threads:[~2018-12-10 14:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-10  4:29 Enlarging w/ xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Inappropriate ioctl for device Nick Bowler
2018-12-10 14:33 ` Brian Foster [this message]
2018-12-10 15:39   ` Nick Bowler
2018-12-10 16:11     ` Brian Foster
2018-12-10 16:50       ` Darrick J. Wong
2018-12-10 16:55         ` Darrick J. Wong
2018-12-10 17:46         ` Brian Foster
2018-12-10 20:54           ` Nick Bowler
2018-12-10 21:41             ` Dave Chinner
2018-12-11  7:04               ` Nick Bowler
2018-12-11 12:27                 ` Brian Foster
2018-12-11 20:13                   ` Nick Bowler
2018-12-11 20:20                     ` Nick Bowler
2018-12-12 13:09                       ` Brian Foster
2018-12-13  0:21                         ` Nick Bowler
2018-12-12  4:56                   ` Nick Bowler
2018-12-13  3:53                     ` Dave Chinner
2018-12-13  4:14                       ` Nick Bowler
2018-12-13  4:49                         ` Nick Bowler
2018-12-13 21:39                           ` Dave Chinner
2018-12-13 21:53                             ` Nick Bowler
2018-12-14  1:43                               ` Dave Chinner
2018-12-14  3:35                             ` Nick Bowler
2018-12-14  3:40                               ` [RFC PATCH xfstests] xfs: add tests to validate ioctl structure layout Nick Bowler
2019-01-15 15:55                                 ` Luis Chamberlain
2018-12-13 16:30                       ` Enlarging w/ xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Inappropriate ioctl for device Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181210143345.GB8356@bfoster \
    --to=bfoster@redhat.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=nbowler@draconx.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.