linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Akira Fujita <a-fujita@rs.jp.nec.com>
To: Andreas Dilger <adilger@sun.com>
Cc: linux-ext4@vger.kernel.org, "Theodore Ts'o" <tytso@mit.edu>
Subject: Re: [RFC][PATCH 1/7]ext4: Add EXT4_IOC_ADD_GLOBAL_ALLOC_RULE	restricts block allocation
Date: Fri, 07 Aug 2009 15:42:32 +0900	[thread overview]
Message-ID: <4A7BCCD8.1070500@rs.jp.nec.com> (raw)
In-Reply-To: <20090623231950.GN31668@webber.adilger.int>

Hi Andreas,

Andreas Dilger wrote:
> On Jun 23, 2009  17:25 +0900, Akira Fujita wrote:
>> alloc_flag of ext4_alloc_rule structure is set as "mandatory" or "advisory".
>> Restricted blocks with "mandatory" are never used by block allocator.
>> But in "advisory" case, block allocator is allowed to use restricted blocks
>> when there are no free blocks on FS.
> 
> Would it make more sense to implement the range protections via the
> existing preallocation ranges (PA)?  An inode can have multiple
> PAs attached to it to have it prefer allocations from that range.
> 
> We could also attach PAs to the superblock to prevent other files from
> allocating out of those ranges.  This would work better with the existing
> allocation code instead of creating a second similar mechanism.

Thank you for comments.

I have considered about the block allocation control with preallocation (PA).
This is my new implementation idea.

a. Block allocation restriction (balloc restriction)
   Redesigned balloc restriction ioctl (EXT4_IOC_BALOC_CONTROL) can set
   and clear protected ranges with flag.
   And balloc restriction used a new type PA (MB_RESTRICT_PA),
   not inode PA (MB_INODE_PA) and group PA (MB_GROUP_PA).

   Previous my patch set has implemented two restriction types: mandatory
   (never used by block allocator) and advisory (used if there is
   no other free blocks to allocate).
   But, to make more simple, I implement only mandatory mode.

   With "SET_BALLOC_RESTRICTION" flag, this ioctl sets MB_RESTRIT_PA,
   and blocks in this PA covers are protected from other block allocator.
   If you want to use these ranges, call with "CLR_BALLOC_RESTRICTIOIN" flag.

   EXT4_IOC_BALLOC_CONTROL calls ext4_mb_new_blocks().  It tries to check
   whether specified range blocks are free or not with mballoc routine.
   If range blocks are free, ext4_mb_new_blocks() sets memory block bitmap
   used (same as ext4 PA), and then adds this information to restriction PA.
   But it does *not* set disk block bitmap used, because these blocks are part of PA.

   ext4_prealloc_space has a new list structure "pa_restrict_list" which holds
   restriction PA passed from user-space.
   ext4_group_info also has a new list structure "bb_restrict_request" which holds
   block group related restriction range.
   This list is used, when we calculate blocks count which are free
   but can not use because of restriction PA.


b. Preferred block allocation for inode (preferred balloc)
   EXT4_IOC_ADD_PREALLOC adds specified blocks to the inode PA.
   You can set arbitrary blocks ranges to inode PA,
   this is the different from fallocate.


   Ext4 inode PA is removed when file is closed, therefore it is not
   necessary to implement to clear inode PA.

Ioctl interfaces are as follows.

a. EXT4_IOC_BALLOC_CONTROL (Set or clear balloc restriction)

     EXT4_IOC_BALLOC_CONTROL
	_IOW('f', 16, struct ext4_balloc_control balloc_control)

     struct ext4_balloc_control {
       __u64 start; /* start physical block offset balloc rest */
       __u64 len;   /* block length */
       __u32 flags; /* set or clear */
     }

    "flags" can be set following 2 types.
    - SET_BALLOC_RESTRICTION
        Set blocks in range to the balloc restriction list.
    - CLR_BALLOC_RESTRICTION
        Clear blocks from the balloc restriction list.

b. EXT4_IOC_ADD_PREALLOC (Add inode preferred range)

     EXT4_IOC_ADD_PREALLOC _IOW('f', 18, struct ext4_balloc_control)

     struct ext4_balloc_control {
       __u64 start; /* start physical block offset */
       __u64 len;   /* block length */
       __u32 flags;  /* create and add mode for inode PA  */
     }

    "flags" must include one of the following create modes
    (MANDATORY or ADVISORY).  In addition, one of the control modes also must
    be set (REPLACER_INODE_PREALLOC or ADD_INODE_PREALLOC).
     Create modes:
     - MANDATORY
         Find free extent which satisfies "start" and "len" completely.
     - ADVISORY
         Try to find free extent from "start" and "len" blocks.
     Control modes:
     - REPLACE_INODE_PREALLOC
         Remove existed inode PA first, and then add specified range to
         the inode PA list newly.
     - ADD_INODE_PREALLOC
         Add specified range to the inode PA list.

     e.g.  flag = MANDATORY | ADD_INODE_PREALLOC
           Find free extent which fulfills the requirements completely,
           and if succeed, add this extent to the inode PA.

Regards,
Akira Fujita


  parent reply	other threads:[~2009-08-07  6:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-23  8:25 [RFC][PATCH 1/7]ext4: Add EXT4_IOC_ADD_GLOBAL_ALLOC_RULE restricts block allocation Akira Fujita
2009-06-23 23:19 ` Andreas Dilger
2009-06-24  0:02   ` Greg Freemyer
2009-06-24  0:11     ` Andreas Dilger
2009-06-25 12:47       ` Greg Freemyer
2009-06-27 16:54         ` Aneesh Kumar K.V
2009-08-07  6:42   ` Akira Fujita [this message]
2009-08-09 18:18     ` Greg Freemyer
2009-10-16  6:47       ` Kazuya Mio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A7BCCD8.1070500@rs.jp.nec.com \
    --to=a-fujita@rs.jp.nec.com \
    --cc=adilger@sun.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).