From: Ruben Porras <nahoo82@gmail.com>
To: David Chinner <dgc@sgi.com>
Cc: xfs@oss.sgi.com, cw@f00f.org, iusty@k1024.org
Subject: Re: XFS shrink functionality
Date: Thu, 14 Jun 2007 10:35:27 +0200 [thread overview]
Message-ID: <1181810127.6539.13.camel@localhost> (raw)
In-Reply-To: <20070608151223.GF86004887@sgi.com>
[-- Attachment #1: Type: text/plain, Size: 1824 bytes --]
> > I took a look at both items since this discussion started. And honestly,
> > I think 1) is harder that 4), so you're welcome to work on it :) The
> > points that make it harder is that, per David's suggestion, there needs
> > to be:
> > - define two new transaction types
>
> one new transaction type:
>
> XFS_TRANS_AGF_FLAGS
done
> and and extension to xfs_alloc_log_agf(). Is about all that is
> needed there.
still to do. Will come after the ioctls.
> See the patch here:
>
> http://oss.sgi.com/archives/xfs/2007-04/msg00103.html
>
> For an example of a very simlar transaction to what is needed
> (look at xfs_log_sbcount()) and very similar addition to
> the AGF (xfs_btreeblks).
>
> > - define two new ioctls
>
> XFS_IOC_ALLOC_ALLOW_AG, parameter xfsagnumber_t.
> XFS_IOC_ALLOC_DENY_AG, parameter xfsagnumber_t.
almost done. How I'm should I obtain a pointer to an xfs_agf_t from
inside the ioctls?
I guess that the first step is to get a *bp with xfs_getsb and then an *sbp,
but, which function/macro gives me the xfs_agf_t pointer? Sorry, I can't
find the way greeping through the code.
> > - update the ondisk-format (!), if we want persistence of these flags;
> > luckily, there are two spare fields in the AGF structure.
>
> Better to expand, I think. The AGF is a sector in length - we can
> expand the structure as we need to this size without fear, esp. as
> the part of the sector outside the structure is guaranteed to be
> zero. i.e. we can add a fields flag to the end of the AGF
> structure - old filesystems simple read as "no flags set" and
> old kernels never look at those bits....
done.
> > - check the list of allocation functions that allocate space from the
> > AG
still to be done.
Thaks again for the help.
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-06-14 8:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-01 16:39 XFS shrink functionality Ruben Porras
2007-06-04 0:16 ` David Chinner
2007-06-04 8:41 ` Iustin Pop
2007-06-04 9:21 ` David Chinner
2007-06-05 8:00 ` Iustin Pop
2007-06-06 1:50 ` Nathan Scott
2007-06-07 8:18 ` David Chinner
2007-06-08 8:23 ` Ruben Porras
2007-06-08 10:15 ` Iustin Pop
2007-06-08 15:12 ` David Chinner
2007-06-08 16:03 ` Iustin Pop
2007-06-09 2:15 ` David Chinner
2007-06-08 19:47 ` Ruben Porras
2007-06-14 8:35 ` Ruben Porras [this message]
2007-06-14 9:14 ` David Chinner
2007-06-08 14:44 ` David Chinner
2007-06-19 22:22 ` XFS shrink (step 0) Ruben Porras
2007-06-19 23:42 ` David Chinner
2007-06-28 10:38 ` Ruben Porras
2007-06-29 6:55 ` David Chinner
2007-07-30 17:30 ` Ruben Porras
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=1181810127.6539.13.camel@localhost \
--to=nahoo82@gmail.com \
--cc=cw@f00f.org \
--cc=dgc@sgi.com \
--cc=iusty@k1024.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox