public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Ruben Porras <ruben.porras@linworks.de>
To: David Chinner <dgc@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: porting xfs_reno to linux
Date: Wed, 14 Nov 2007 15:19:22 +0100	[thread overview]
Message-ID: <473B03EA.2040002@linworks.de> (raw)
In-Reply-To: <20071113210018.GX995458@sgi.com>

David Chinner schrieb:
> On Tue, Nov 13, 2007 at 07:20:59PM +0100, Ruben Porras wrote:
>   
>> Let's go back to the shrink xfs theme.
>>
>>     
>>> 2. Move inodes out of offline AGs
>>> 		- On Irix, we have a program called 'xfs_reno' which
>>> 		  converts 64 bit inode filesystems to 32 bit inode
>>> 		  filesystems. This needs to be:
>>> 		  	- released under the GPL (should not be a problem).
>>>       
>> done
>>
>>     
>>> 			- ported to linux
>>>       
>> Do you mean, rewrite the program to work on kernel space,
>>     
>
> No.
>
>   
>> or just port it 
>> to glibc?
>>     
>
> Port to linux. i.e. make it work and remove any tainted code that it
> might contain from  Irix so we can open source it.  Barry has
> already done this; the patch is here:
>
> http://oss.sgi.com/archives/xfs/2007-10/msg00054.html
>
> All it needs is reviewing and then xfs_reno for linux is done.
>
>   
Sorry, I didn't exlplain myself well enough. I already saw the mail from 
Barry, but the program needs not only a review. Now xfs_reno filter the 
inodes with nftw and the stat info. The problem is that we need to 
filter the inodes according to the AG where they are. Currently there is 
no way to find this out. Possibilities:

a) Extend the bulkstat structure to include the AG number (better not)
b) A new ioctl to find out the AG of an inode. and call the ioctl for 
each file on the fs.
c) Find all the inodes in 'marked' AGs. Export it through a new ioctl. 
xfs_reno needs to find later which files on the fs were on the list.

The second way would be to do everything in kernel space. The steps 
would be:

a) Find all the inodes in 'marked' AGs
b) Allocate a new inode for each one
c) Move the information from each old inode to the new one and unlink 
the old one. (This is what Barry suggest to do anyway in kernel space)

xfs_reno does only steps b) and c).

The second needs more work, but it doesn't need to traverse the 
filesystem several times.
> Cheers,
>
> Dave.
>   


-- 
Rubén Porras
LinWorks GmbH

      reply	other threads:[~2007-11-14 14:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-13 18:20 porting xfs_reno to linux Ruben Porras
2007-11-13 21:00 ` David Chinner
2007-11-14 14:19   ` Ruben Porras [this message]

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=473B03EA.2040002@linworks.de \
    --to=ruben.porras@linworks.de \
    --cc=dgc@sgi.com \
    --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