linux-ext4 - Re: [Ext4 punch hole 1/6 v5] Ext4 Punch Hole Support: Add flag to ext4_has_free

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: <20110428120859.GA1696@quack.suse.cz>
Date:	Thu, 28 Apr 2011 14:08:59 +0200
From:	Jan Kara <jack@...e.cz>
To:	Amir Goldstein <amir73il@...il.com>
Cc:	Allison Henderson <achender@...ux.vnet.ibm.com>,
	Yongqiang Yang <xiaoqiangnk@...il.com>,
	linux-ext4@...r.kernel.org, Mingming Cao <cmm@...ibm.com>,
	Theodore Tso <tytso@....edu>, Jan Kara <jack@...e.cz>,
	Eric Sandeen <sandeen@...hat.com>
Subject: Re: [Ext4 punch hole 1/6 v5] Ext4 Punch Hole Support: Add flag to
 ext4_has_free_blocks

On Thu 28-04-11 09:28:53, Amir Goldstein wrote:
> On Wed, Apr 27, 2011 at 11:44 PM, Allison Henderson
> <achender@...ux.vnet.ibm.com> wrote:
> > On 4/25/2011 10:44 AM, Amir Goldstein wrote:
> > Hi All,
> >
> > I did some looking around with the idea of using an allocation_request
> > instead of a flags parameter, but I noticed that ext4_new_meta_blocks is
> > already setting up an allocation_request to pass to ext4_mb_new_blocks.
> >  Would it make sense then that we add an "ar_flags" parameter instead of a
> > "flag" or another "ar" parameter?  That way, ext4_new_meta_blocks can just
> > add the flags to the ar that it already has, and we wouldn't have to change
> > the ext4_mb_new_blocks parameters.  And then USE_ROOTBLKS can be added on to
> > the EXT4_MB_HINT scheme instead of starting a new scheme.  That would avoid
> > the extra ar initializing. What does everybody think?  Would this work for
> > the HINT_COWING flag?
> 
> I think this would be perfect.
> ext4_new_meta_blocks() is not much more than a helper to setup the ar struct,
> so passing 'flags' (in that context I see no reason to call it
> ar_flags) to it makes sense.
> The important thing is that USE_ROOTBLKS is added to the EXT4_MB_HINT scheme
> and passed all the way down to has_free_blocks with the 'ar' struct.
> 
> This discussion makes me wonder (CC'ing Jan and Eric for that), wasn't
> there ever an intention
> to allow the use of reserved space for allocation of any metadata blocks?
  Not that I know of.

> The use case is delayed allocation combined with async mmap writes.
> Do we always account for enough metadata blocks when doing delayed allocation?
> Both for extent and indirect mapped files?
  Yes, both should make appropriate upper estimates on the number of needed
blocks and reserve that amount. With indirect blocks it's kind of tricky
but the code should be correct.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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