linux-ext4 - Re: [PATCH 1/1] dir shrink

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200908302115.32536.schlick@lavabit.com>
Date:	Sun, 30 Aug 2009 21:15:32 +0200
From:	Andreas Schlick <schlick@...abit.com>
To:	Andreas Dilger <adilger@....com>
Cc:	Theodore Tso <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/1] dir shrink

Hello,

On Saturday 29 August 2009, Andreas Dilger wrote:
> > As I understand it, Ted's idea was to avoid problems with the
> > transactions by doing it after the main work of
> > unlink()/rmdir()/rename(). I don't know what the better approach is and
> > don't mind changing it.
> This seems reasonable, though in that case it seems it would be much
> more efficient to just put the directory inode onto an in-memory list
> of directories that have recently emptied a block, and then have a
> separate helper thread (or kernel task or whatever) that checks this
> list periodically and does freeing of all blocks at the end of the
> file that are empty.

But is deleting a huge number of files common enough that the increase in code 
complexity pays off? I'd expect that it doesn't happen often enough to gain 
much. And if it gets more complex, I'd like to have the base functionality 
tested first, so would the patch be acceptable as it is?

Andreas Schlick

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html