[Top] [All Lists]

Re: [PATCH v5 00/10] speculative preallocation inode tracking

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: [PATCH v5 00/10] speculative preallocation inode tracking
From: Brian Foster <bfoster@xxxxxxxxxx>
Date: Sun, 21 Oct 2012 10:00:35 -0400
Cc: xfs@xxxxxxxxxxx
In-reply-to: <5081BFFF.70603@xxxxxxx>
References: <1349446636-8611-1-git-send-email-bfoster@xxxxxxxxxx> <5081BFFF.70603@xxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1
On 10/19/2012 05:02 PM, Mark Tinguely wrote:
> On 10/05/12 09:17, Brian Foster wrote:
>> Hi all,
>> This is v3 of the speculative preallocation inode tracking patchset. This
>> functionality tracks inodes with post-EOF speculative preallocation
>> for the
>> purpose of background and on-demand trimming.
>> Background scanning occurs on a longish interval (5 minutes by
>> default) and in
>> a best-effort mode (i.e., inodes are skipped due to lock contention or
>> dirty
>> cache). The intent is to clear up post-EOF blocks on inodes that might
>> have
>> allocations hanging around due to open-write-close sequences (NFS).
>> On demand scanning is provided via a new ioctl and supports various
>> parameters
>> such as scan mode, filtering by quota id and minimum file size. A
>> pending use
>> case for on demand scanning is for accurate quota accounting via the
>> gluster
>> scale out filesystem (i.e., to free up preallocated space when near a
>> usage
>> limit).
>> Brian
> The series looks great.

Hi Mark,

Thanks for the review.

> I am just curious, what is the reason for the padding in the
> xfs_eofblocks structure?

I added the padding in response to review on an early revision of the set:


The purpose is to allow adding fields to the control structure down the
road without breaking existing binaries.


> Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>

<Prev in Thread] Current Thread [Next in Thread>