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  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]
Date:	Thu, 28 Apr 2011 14:08:59 +0200
From:	Jan Kara <>
To:	Amir Goldstein <>
Cc:	Allison Henderson <>,
	Yongqiang Yang <>,, Mingming Cao <>,
	Theodore Tso <>, Jan Kara <>,
	Eric Sandeen <>
Subject: Re: [Ext4 punch hole 1/6 v5] Ext4 Punch Hole Support: Add flag to

On Thu 28-04-11 09:28:53, Amir Goldstein wrote:
> On Wed, Apr 27, 2011 at 11:44 PM, Allison Henderson
> <> 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.

Jan Kara <>
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists