xfs
[Top] [All Lists]

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

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: [PATCH v5 00/10] speculative preallocation inode tracking
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Sun, 21 Oct 2012 12:53:19 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <50840003.406@xxxxxxxxxx>
References: <1349446636-8611-1-git-send-email-bfoster@xxxxxxxxxx> <5081BFFF.70603@xxxxxxx> <50840003.406@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 10/21/12 09:00, Brian Foster wrote:
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:

http://oss.sgi.com/archives/xfs/2012-09/msg00024.html

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

Brian

Reviewed-by: Mark Tinguely<tinguely@xxxxxxx>


Thank-you for the information.

I would think that changing the number of arguments would also
involving changing the version number. The kernel should know
that version 1 copies in 16 bytes, version 2 copies in 16+t bytes,
version n copies in 16+n bytes...

Not at all a big deal, (16 used and 12 padding = ) 28 bytes was an
odd number and it got my curiosity up. I suspected it was part a plan
of yours and Pinky to take over the world. :)

Nice feature. I jury-rigged a ioctl to test and it works great. I look
forwarded to seeing this in xfs_io.

--Mark.

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