From: Mike Fleetwood <mike.fleetwood@googlemail.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Dave Chinner <david@fromorbit.com>,
Tarik Ceylan <Tarik.Ceylan@ruhr-uni-bochum.de>,
linux-xfs@vger.kernel.org
Subject: Re: How to reliably measure fs usage with reflinks enabled?
Date: Sat, 19 May 2018 09:36:54 +0100 [thread overview]
Message-ID: <CAMU1PDgUFvA6qTbMoWjPck_oN2EjH6C_Jy63suTgqpnXCzpw6w@mail.gmail.com> (raw)
In-Reply-To: <f220ccc1-00ed-879e-94d0-33cb9d5a1e37@sandeen.net>
On 18 May 2018 at 15:56, Eric Sandeen <sandeen@sandeen.net> wrote:
> On 5/18/18 9:43 AM, Mike Fleetwood wrote:
>>
>> (Sorry for the late reply, work commitments)
>>
> ...
>
>> So after checking, GParted was modified to use the dumpe2fs command to
>> read the superblock to get the file system size for mounted ext* file
>> systems too.
>>
>> https://marc.info/?l=linux-ext4&m=134706477618732&w=2
>>
>> I see that xfs_db doesn't allow reading the super block of mounted XFS
>> file systems. So for the case of a mounted XFS on full fat block device
>> I guess I'll wait and see how much overhead is subtracted from the
>> statvfs f_blocks figure and make sure GParted accounts for that.
>
>
> Actually you can, with -r:
>
> # mount /dev/sda1 /mnt/test
> # xfs_db -r -c "sb 0" -c "p dblocks" /dev/sda1
> dblocks = 229771264
>
> though I may be giving you rope to hang yourself here ;)
>
> It's generally a bit dicey to be reading a mounted block device for any
> filesystem, as there's no coordination with changes the filesystem may
> be making while it's mounted.
>
> The XFS_IOC_FSGEOMETRY would be a better choice for gathering geometry
> information for a mounted xfs filesystem.
Thanks, the xfs_db -r option is exactly what I need. (Should have
checked the man page myself for that).
Mike
next prev parent reply other threads:[~2018-05-19 8:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-14 20:02 How to reliably measure fs usage with reflinks enabled? Tarik Ceylan
2018-05-14 22:02 ` Eric Sandeen
2018-05-14 22:57 ` Dave Chinner
2018-05-14 23:37 ` Tarik Ceylan
2018-05-15 1:29 ` Dave Chinner
2018-05-15 13:52 ` Mike Fleetwood
2018-05-16 0:13 ` Dave Chinner
2018-05-18 14:43 ` Mike Fleetwood
2018-05-18 14:56 ` Eric Sandeen
2018-05-19 8:36 ` Mike Fleetwood [this message]
2018-05-18 14:58 ` Darrick J. Wong
2018-05-20 0:10 ` Dave 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=CAMU1PDgUFvA6qTbMoWjPck_oN2EjH6C_Jy63suTgqpnXCzpw6w@mail.gmail.com \
--to=mike.fleetwood@googlemail.com \
--cc=Tarik.Ceylan@ruhr-uni-bochum.de \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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.