cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
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.




  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).