From: Vlad Apostolov <vapo@sgi.com>
To: lachlan@sgi.com
Cc: xfs-dev <xfs-dev@sgi.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] bulkstat fixups
Date: Fri, 09 Nov 2007 16:35:20 +1100 [thread overview]
Message-ID: <4733F198.1090107@sgi.com> (raw)
In-Reply-To: <4733EEF2.9010504@sgi.com>
It is looking good Lachlan.
I also verified the patch with XFS QA and Judith reported that
it fixed the xfs_bulkstat() problem - skipping inodes in the last AG.
Regards,
Vlad
Lachlan McIlroy wrote:
> Here's a collection of fixups for bulkstat for all the remaining issues.
>
> - sanity check for NULL user buffer in xfs_ioc_bulkstat[_compat]()
>
> - remove the special case for XFS_IOC_FSBULKSTAT with count == 1.
> This special
> case causes bulkstat to fail because the special case uses
> xfs_bulkstat_single()
> instead of xfs_bulkstat() and the two functions have different
> semantics.
> xfs_bulkstat() will return the next inode after the one supplied
> while skipping
> internal inodes (ie quota inodes). xfs_bulkstate_single() will only
> lookup the
> inode supplied and return an error if it is an internal inode.
>
> - in xfs_bulkstat(), need to initialise 'lastino' to the inode
> supplied so in cases
> were we return without examining any inodes the scan wont restart
> back at zero.
>
> - sanity check for valid *ubcountp values. Cannot sanity check for
> valid ubuffer
> here because some users of xfs_bulkstat() don't supply a buffer.
>
> - checks against 'ubleft' (the space left in the user's buffer) should
> be against
> 'statstruct_size' which is the supplied minimum object size. The
> mixture of
> checks against statstruct_size and 0 was one of the reasons we were
> skipping
> inodes.
>
> - if the formatter function returns BULKSTAT_RV_NOTHING and an error
> and the error
> is not ENOENT or EINVAL then we need to abort the scan. ENOENT is
> for inodes that
> are no longer valid and we just skip them. EINVAL is returned if we
> try to lookup
> an internal inode so we skip them too. For a DMF scan if the inode
> and DMF
> attribute cannot fit into the space left in the user's buffer it
> would return
> ERANGE. We didn't handle this error and skipped the inode. We
> would continue to
> skip inodes until one fitted into the user's buffer or we completed
> the scan.
>
> - put back the recalculation of agino (that got removed with the last
> fix) at the
> end of the while loop. This is because the code at the start of the
> loop expects
> agino to be the last inode examined if it is non-zero.
>
> - if we found some inodes but then encountered an error, return
> success this time
> and the error next time. If the formatter aborted with ENOMEM we
> will now return
> this error but only if we couldn't read any inodes. Previously if
> we encountered
> ENOMEM without reading any inodes we returned a zero count and no
> error which
> falsely indicated the scan was complete.
next prev parent reply other threads:[~2007-11-09 5:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-09 5:24 [PATCH] bulkstat fixups Lachlan McIlroy
2007-11-09 5:35 ` Vlad Apostolov [this message]
2007-11-11 21:48 ` David Chinner
2007-11-12 2:57 ` Lachlan McIlroy
2007-11-12 4:11 ` David Chinner
2007-11-16 4:34 ` Lachlan McIlroy
2007-11-16 4:42 ` Lachlan McIlroy
2007-11-19 3:02 ` David Chinner
2007-11-21 15:17 ` Christoph Hellwig
2007-11-21 21:31 ` David Chinner
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=4733F198.1090107@sgi.com \
--to=vapo@sgi.com \
--cc=lachlan@sgi.com \
--cc=xfs-dev@sgi.com \
--cc=xfs@oss.sgi.com \
/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.