[Top] [All Lists]

Re: hole punching performance

To: "Bradley C. Kuszmaul" <kuszmaul@xxxxxxxxx>
Subject: Re: hole punching performance
From: Ben Myers <bpm@xxxxxxx>
Date: Sun, 13 Jan 2013 13:49:41 -0600
Cc: Florian Weimer <fw@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <CAKSyJXfQsmemZ3H9A92UezsPCXfn37LXP3tpPMkiwtvR4=eY2g@xxxxxxxxxxxxxx>
References: <CAKSyJXf66H2U-BF-aYnSr2fF24_6LJw6swOx1RhUc_3Eqayaiw@xxxxxxxxxxxxxx> <87pq195t8q.fsf@xxxxxxxxxxxxxxxxx> <CAKSyJXfQsmemZ3H9A92UezsPCXfn37LXP3tpPMkiwtvR4=eY2g@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
Hey Florian & Bradley,

On Sun, Jan 13, 2013 at 11:36:27AM -0500, Bradley C. Kuszmaul wrote:
> Where can I read about extents and xfs?

Look here:

> On Sun, Jan 13, 2013 at 4:26 AM, Florian Weimer <fw@xxxxxxxxxxxxx> wrote:
> > * Bradley C. Kuszmaul:
> >
> > > The question I have:  What will happen to the performance of other
> > > threads doing read() and write() operations?  Will hole-punching slow
> > > down the other read() and write() operations running in other threads?
> >
> > Assuming that hole-punching creates extents (not sure if it does, you
> > can check with filefrag or other tools),

Yep, it can.  For example, if you have one large extent and punch out the
middle you end up with two in the block map.  Use xfs_bmap to look at the
extent list.
>       you might experience a
> > slowdown during open(), when the entire list of extents is read from disk.

The docs probably describe this better than I can, see the data extents section
of the filesystem structure doc.  Inline extent lists would already have been
read in with the inode, so it's not more expensive than reading the inode
itself because it's in the same block.  If you have a large extent list in a
btree you can expect it to be read in as you access the data.

> > I once was a heavy Berkeley DB user and had files with dozens of gigabytes
> > containing hundreds of thousands of extents, and open() times in the order
> > of minutes were not unusual with a cold cache and other concurrent read
> > activities from the same RAID device.

Ouch.  I would not have expected open times that bad.

> > But these files grew over
> > timeâperhaps hole punching results in better locality of the extent data,
> > so that reading it doesn't take so much time in your case.

xfs_bmap could help answer that question...  ;)


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