From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Recording extents in GFS2
Date: Mon, 14 Dec 2020 10:46:52 +0000 [thread overview]
Message-ID: <878be018-3ff8-5c7d-e5c6-db6513b6de1c@redhat.com> (raw)
In-Reply-To: <CACrDRjiiXtz6cOO8FmnZHKte2EVKAFzDESXJ5a8oALd7h+EizA@mail.gmail.com>
Hi,
On 11/12/2020 16:38, Abhijith Das wrote:
> Hi all,
>
> With a recent set of patches, we nearly eliminated the per_node statfs
> change files by recording that info in the journal. The files and some
> recovery code remain only for backward compatibility. Similarly, I'd
> like to get rid of the per_node quota change files and record that
> info in the journal as well.
>
> I've been talking to Andreas and Bob a bit about this and I'm
> investigating how we can record extents as we allocate and deallocate
> blocks instead of writing whole blocks. I'm looking into how XFS does
> this.
>
> We could have a new journal block type that adds a list of extents to
> inodes with alloc/dealloc info. We could add in quota (uid/gid) info
> to this as well. If we can do this right, the representation of
> alloc/dealloc becomes compact and consequently we use journal space
> more efficiently. We can hopefully avoid cases where we need to zero
> out blocks during allocation as well.
>
> I'm sending this out to start a discussion and to get ideas/comments/pointers.
>
> Cheers!
> --Abhi
>
I think you need to propose something a bit more concrete. For example
what will the data structures look like? How many entries will fit in a
journal block at different block sizes? How will we ensure that this is
backwards compatible? That will make it easier to have the discussions,
Steve.
next prev parent reply other threads:[~2020-12-14 10:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-11 16:38 [Cluster-devel] Recording extents in GFS2 Abhijith Das
2020-12-14 10:46 ` Steven Whitehouse [this message]
2021-01-24 6:44 ` Abhijith Das
2021-02-02 15:08 ` Bob Peterson
2021-02-02 17:35 ` Steven Whitehouse
2021-02-20 9:48 ` Andreas Gruenbacher
2021-02-22 10:20 ` Steven Whitehouse
2021-02-22 11:41 ` Andreas Gruenbacher
2021-02-22 13:03 ` Andreas Gruenbacher
2021-02-25 18:48 ` Bob Peterson
2021-02-25 19:08 ` Andreas Gruenbacher
2021-02-25 19:45 ` Bob Peterson
2021-03-01 17:53 ` Andreas Gruenbacher
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=878be018-3ff8-5c7d-e5c6-db6513b6de1c@redhat.com \
--to=swhiteho@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).