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  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:	Wed, 7 Mar 2012 12:14:43 +0800
From:	Andreas Dilger <aedilger@...il.com>
To:	Dave Chinner <david@...morbit.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [RFC] fadvise: add more flags to provide a hint for block allocation

On 2012-03-07, at 8:51 AM, Dave Chinner wrote:
> On Mon, Mar 05, 2012 at 08:50:29PM +0800, Zheng Liu wrote:
>> 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_SEQ
> 
> fallocate()

I think this is already the assumed default for any file IO, but is included for completeness (e.g. to be able to turn off READ_RANDOM).

>> FADV_ALLOC_READ_RANDOM
> 
> Allocation can't be optimised as the read pattern cannot be defined.

I think what this is intended for is to tell the filesystem "don't work very hard to find optimum allocation, it will have a random read pattern anyway".

>> FADV_ALLOC_WRITE_ONCE
> 
> fallocate()
> 
>> FADV_ALLOC_WRITE_APPEND
> 
> chattr +a

and/or fallocate(KEEP_SIZE)

Having a consistent API definitely makes sense.

This proposal definitely needs to have some clear explanation of how the flags are intended to be used by applications, and why they will help filesystems to improve allocation.  I'm not for adding gratuitous APIs, but at the same time I think that filesystems are often working in the dark and could benefit from more information being passed from the application.

Cheers, Andreas





--
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

Powered by blists - more mailing lists