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] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 6 Mar 2012 21:56:56 +0800
From:	Zheng Liu <>
To:	Lukas Czerner <>
Subject: Re: [RFC] fadvise: add more flags to provide a hint for block

On Tue, Mar 06, 2012 at 09:27:16AM +0100, Lukas Czerner wrote:
> On Mon, 5 Mar 2012, Zheng Liu wrote:
> > Hi list,
> > 
> > Block allocation is a key component of file system.  Every file systems try to
> > improve the performance with optimizing the block allocation of a file.  But no
> > matter what file system does, it just guesses what the user expects.  Thus, it
> > is not very accurate.  fadvise(2) provides a method to let the user to give a
> > hint to file system.  However, until now, only few flags are provided.  So we
> > can provide more flags to tell file system how to allocate the blocks for a
> > file.
> > 
> > For example:
> > we can add these flags into fadvise(2):
> > 
> > FADV_ALLOC_READ_* are not similar with FADV_SEQUENTIAL and FADV_RANDOM.
> > FADV_ALLOC_READ_SEQ tells file system that this file need to allocate some
> > sequential blocks, and FADV_ALLOC_READ_RADOM tells file system that this file
> > can endure the fragmentation.
> > 
> > FADV_ALLOC_WRITE_ONCE indicates that this file just is written once.  So file
> > system can allocate some sequential blocks for it to improve the read
> > performance.  FADV_ALLOC_WRITE_APPEND flag is set to point out that data will be
> > appended to the end of this file, and file system can reserve some blocks for it
> > to guarantee the sequence as much as possible.
> Hi Zheng,
> those two flags does not make sense to me. The FADV_ALLOC_WRITE_ONCE is
> actually the same as fallocate, and we certainly do not need more ways
> to do fallocate, one is more than enough.
> FADV_ALLOC_WRITE_APPEND seems weird. File systems already do some
> preallocations for the files, so we do not fragment them as much. So
> what might be more interesting is to be able to set how much space we
> want to keep preallocated for the particular file, however strictly
> speaking it is not something we would not achieve with fallocate, but it
> would certainly be more convenient.
> -Lukas

Hi Lukas,

I have realized that these two flags seem redundant, and we don't need

As we discussed previously and Sunil's suggestions.  The key issue is
that user provides a hint to file system, and file system can know
whether or not this file can be stored in a corner or be allocated in
non-sequential blocks.  Then the sequential blocks are reserved for the
particular file that has a *_HOT* flag.  Although fallocate(2) can
preallocate some blocks for a file, it cannot put a file at the
beginning of the disk to obtain a better performance.  So maybe file
system can use these flags to optimize the layout of a file.


> > 
> > File systems can support a subset of these flags according to its design.  These
> > flags provide a rich interface that lets the user to control block allocation of
> > files.  The user could precisely control the allocation of their files to
> > improve the performance of appliatons.
> > 
> > Any comments or suggestions are appreciated.  Thank you.
> > 
> > Regards,
> > Zheng
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> > the body of a message to
> > More majordomo info at
> > 
> -- 
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