lkml.org 
[lkml]   [2002]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Shrinking ext3 directories


On Tue, 18 Jun 2002, Stephen C. Tweedie wrote:

> Hi,
>
> On Tue, Jun 18, 2002 at 06:08:28PM +0200, DervishD wrote:
>
> > All of you know that if you create a lot of files or directories
> > within a directory on ext2/3 and after that you remove them, the
> > blocks aren't freed (this is the reason behind the lost+found block
> > preallocation). If you want to 'shrink' the directory now that it
> > doesn't contain a lot of leafs, the only solution I know is creating
> > a new directory, move the remaining leafs to it, remove the
> > 'big-unshrinken' directory and after that renaming the new directory
>
> Right. Shrinking directories is not implemented for ext2 or ext3 at
> the moment. However, I know that Daniel Phillips has been thinking
> about adding that for his HTree extensions which add fast directory
> indexing to ext2/3.

<shrug> for ext2 a limited form of "shrinking" is easy to implement.
ext2_delete_entry() can easily notice that it's about to create an
empty entry spanning entire last block. In that case it should
just walk back and check beginnings of previous blocks, as long
as they are empty (inode = 0, len = block size). Then it's vmtruncate()
time - all IO on directories is protected by i_sem, so we are safe.

IOW, making sure that empty blocks in the end of directory get freed
is a matter of 10-20 lines. If you want such patch - just tell, it's
half an hour of work...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:26    [W:0.143 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site