All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Andrey Albershteyn <aalbersh@redhat.com>, util-linux@vger.kernel.org
Subject: Re: [PATCH 0/2] libblkid: add FSSIZE with XFS implementation
Date: Tue, 26 Apr 2022 10:21:04 +0200	[thread overview]
Message-ID: <20220426082104.fojzjdfprbb2dth7@ws.net.home> (raw)
In-Reply-To: <8b2a82b2-8890-1276-9948-d8c28fca3d9b@redhat.com>

On Mon, Apr 25, 2022 at 10:38:02AM -0500, Eric Sandeen wrote:
> On 4/25/22 8:43 AM, Karel Zak wrote:
> > 
> >  Thanks Andrey,
> > 
> > the code looks good.
> > 
> > On Thu, Apr 21, 2022 at 03:09:44PM +0200, Andrey Albershteyn wrote:
> >> I had a look into other fs, like ext4 and btrfs, to implement FSSIZE
> >> for them, but I think I don't have enough expertize to do that as
> >> they have not so trivial metadata overhead calculation :)
> > 
> > But it would be nice to have ext4 and btrfs too. Maybe Eric can help
> > you :-)
> > 
> >     Karel
> 
> For ext4 something like e2fsprogs does is probably ok:
> 
> static __u64 e2p_free_blocks_count(struct ext2_super_block *super)
> {
>         return super->s_free_blocks_count |
>                 (ext2fs_has_feature_64bit(super) ?
>                 (__u64) super->s_free_blocks_hi << 32 : 0);
> }
> 
> though I wonder if a little documentation on the intent of the flag is
> in order; ext4 can return "df" in different ways (see the minixdf and
> bsddf mount options.)
> 
> I think best effort seems fine here, and reporting the same number
> as the ext4 utilities do should be fine.

Yes, that's good enough.

> As for btrfs - I'm really not sure what this should return on a
> multi-device filesystem?

Hmm ... good point. I guess the right answer is return nothing,
because we really don't want any complicated fs-specific logic in
libblkid.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com


  reply	other threads:[~2022-04-26  8:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21 13:09 [PATCH 0/2] libblkid: add FSSIZE with XFS implementation Andrey Albershteyn
2022-04-21 13:09 ` [PATCH 1/2] libblkid: add interface for FSSIZE field Andrey Albershteyn
2022-04-25 13:40   ` Karel Zak
2022-04-21 13:09 ` [PATCH 2/2] libblkid: implement FSSIZE calculation for XFS Andrey Albershteyn
2022-04-25 13:43 ` [PATCH 0/2] libblkid: add FSSIZE with XFS implementation Karel Zak
2022-04-25 15:38   ` Eric Sandeen
2022-04-26  8:21     ` Karel Zak [this message]
     [not found]       ` <YmfPPbgZtZi1iSXv@aalbersh.remote.csb>
2022-04-27  4:10         ` Eric Sandeen
2022-04-29  8:43           ` Karel Zak

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=20220426082104.fojzjdfprbb2dth7@ws.net.home \
    --to=kzak@redhat.com \
    --cc=aalbersh@redhat.com \
    --cc=sandeen@redhat.com \
    --cc=util-linux@vger.kernel.org \
    /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.