Date: Mon, 5 Sep 2005 21:52:21 +0300
From: Iustin Pop <iusty@k1024.org>
To: linux-xfs@oss.sgi.com
Subject: Where/how to submit for review patch for shrink support?
Message-ID: <20050905185221.GA5209@saytrin.hq.k1024.org>
Mail-Followup-To: linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6"
Content-Disposition: inline
User-Agent: Mutt/1.5.10i
Sender: linux-xfs-bounce@oss.sgi.com
Errors-to: linux-xfs-bounce@oss.sgi.com
Precedence: bulk
Content-Length: 3666
Lines: 90

--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hello to all,

I would like to know in what form should I submit my patch and where
(probably to the list). The diff I have was made against 2.6.12.5 and
applies/compiles cleanly against 2.6.13 also.

Detailed explanation: I've completed the first part of the shrink
support:
 - first patch: permits shrink of the filesystem if all requested blocks
   are free;
 - second patch (not yet finished): add support for marking allocation
   groups offline with regard to space and inode allocation so that you
   can clear out the space;
 - third part, probably userspace, which will help clear the indented
   space (using xfs_swap_extents and inode switch maybe).

Now, regarding the first patch. What it does is enable the kernel to
shrink a filesystem if it passes certain checks, which ensure (I
believe) that the space to be removed is free.

The code is almost non-intrusive:
 - it adds a function xfs_shrink_data_private to xfs_fsops.c
 - it modifies xfs_growfs_data_private to call the above function if
   shrinking
 - it adds one function to xfs_alloc_btree.c to enable calculation of
   the bno or cnt btree
 - it adds one function to xfs_ialloc_btree.c to enable calculation of
   the inode btree and the space used by the inode chunks
 - (only intrusive item) it removes from xfs_trans_mod_sb the
   ASSERT(delta > 0); for XFS_TRANS_SB_DBLOCKS and XFS_TRANS_SB_AGCOUNT

Except for the ASSERT() removal, the code is called only and only when
shrinking.

Example of behavior: you have a filesystem of 8 a.g. of 1000 blocks
each, and want to shrink the filesystem from 8000 to 5500 blocks. The
new routine will:
 - check if you have an internal journal and abort if you would trip
   over it;
 - check that you have enough space by making an xfs_trans_reserve
 - for (in this example) the a.g. 6 & 7 (starting from 0), which will be
   completely removed:
   * check that no allocated inodes exist in that a.g. (agi_freecount
      == agi_count)
   * check that the used space in that a.g. is used only by metadata:
     deleted and unreclaimed inodes, inode allocation btrees, bno and
     cnt allocation btrees and freelist
 - for the a.g. 5, it will try and make an exact allocation of space
   from block 500 to the end, which would fail if anything is in that
   space; thus, if the allocation succeeds, it means we can chop off
   that space;

Now the patch does not include memory management stuff (except for a
simple resizing of mp->m_perag if we chop an entire a.g.), since I
didn't understand this issue. Also I'm not sure what can happen in some
inodes or data is in the cache but not flushed, or if this can even
happen when using transactions. Since xfs_growfs_data_private didn't
contain any such stuff, I presumed shrink doesn't also. Probably wrong
assumption...

Testing was done using user mode linux 2.6.12.5 on an i386 host. In the
current state, I can't seem to generate any oops or panics (using
XFS_DEBUG=y manually set in the Makefile), and xfs_check and xfs_repair
do not complain. I also was able to grow-shrink-grow-shrink-.... a
filesystem without problems.

I would like to know if this has any chance of being considered for
inclusion... or if I wasted my time :)

Iustin Pop

--IJpNTDwzlM2Ie8A6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHJPl4mx23Z34NMIRAk6xAJ9EzraqvzFHPUGKte5QWLN9B30IkwCg2fHi
VRrFUCgQkRBRsMub+0iMVRs=
=w6c/
-----END PGP SIGNATURE-----

--IJpNTDwzlM2Ie8A6--