Markus Lidel wrote:
Hi...
could someone help me with freeing a used ag?
I want to do it inside the kernel and while the fs is mounted. I've
already looked at the code, and it looks to me that freeing the agi of
an ag is the easier part, so i want to start with it. I thought i could
look at each inode of the agi i want to free, but i think i must iterate
over each inode when freeing the used blocks anyway. So i iterate over
each inode (starting with the root inode) and move the inode to a new
one if it is inside the ag which should be freed. The second step is to
look at the inode itself. If the data block is inside the ag it could be
moved outside the ag too.
If i missed something until here, please let me know:-)
Make sure you traverse all the inodes - there will probably be inodes
in different allocation groups which have extents in the targeted ag.
When you move an inode you need to fix up all the directories which
point at it. It is going to get a new inode number, so you need to walk
the directory tree looking for that inode number and replacing it. Remember,
hard links mean an inode number could show up more than once.
My questions are:
1. Is there a facility to iterate over each used inode?
Bulkstat as Christoph said.
2. how could i easily copy the inode to a free space outside the current
agi (i thought of setting pag.pagf_freeblks, pag.pagf_flcount,
pag.pagf_longest to 0).
You need a mechanism to drain all the transactions in progress (look at
the freeze code), then flag the per ag structures in some way so that
the allocator will not use them. A temporary in memory flag in the
per ag headers is probably best. Then start up transactions again.
3. have i missed something or is there a better way to do it?
You might want to try this from user space with some kernel assist rather
than doing it all in the kernel. The bulkstat and swap extent calls provide
the meat of the tools you need to do this.
Of course, you need sufficient free space to recreate everything outside those
allocation groups. If you are removing some space from the filesystem, the
allocator probably needs to be told that the filesystem is smaller than it
actually is, or you may get into states where one part of the allocator thinks
there is room, but it cannot actually find the space.
Steve
Any help is appreciated.
Thank you very much in advance.
Best regards,
Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)
Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany
Phone: +49 82 82/99 51-0
Fax: +49 82 82/99 51-11
E-Mail: Markus.Lidel@xxxxxxxxxxxxxxxxx
URL: http://www.shadowconnect.com
|