Date: Fri, 01 Jan 2010 22:21:33 -0800 From: Kirk McKusick <mckusick@mckusick.com> To: Ben Schumacher <me@benschumacher.com> Cc: freebsd-fs@freebsd.org, Jeff Roberson <jroberson@jroberson.net> Subject: Re: snapshot implementation Message-ID: <201001020621.o026LXac038508@chez.mckusick.com> In-Reply-To: <alpine.BSF.2.00.1001011316030.1027@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Fri, 1 Jan 2010 13:19:33 -1000 (HST) > From: Jeff Roberson <jroberson@jroberson.net> > To: Ben Schumacher <me@benschumacher.com> > Cc: freebsd-fs@freebsd.org > Subject: Re: snapshot implementation > > On Tue, 29 Dec 2009, Ben Schumacher wrote: > > > I've recently picked up a copy of "The Design and Implementation of > > the FreeBSD OS", so I'm starting there, but I would love it if anybody > > could toss me a hint or two on what some of the low-hanging fruit in > > the arena might be. I've been playing with ZFS on a few boxes now, but > > I've had (even with FreeBSD 8) enough unusual crashes that I'm > > personally not ready to commit to using it on at least one "mission > > critical" project I'm working on. That being said I'd love to be able > > to do snapshots on the box without it hanging for over an hour due to > > the fact that the data drive is >400GB (frankly on the small side for > > some of the storage applications I've read about on this mailing > > list). > > > > Any hints, tips, pointers would be appreciated. > > > > Cheers, > > Ben > > The daemon book is a good start. I'd say the snapshot problem might be a > bit tough right out of the gate but it could be possible if you have > strong fundamentals and someone experienced mentors you. > > Why don't you read a bit of the daemon book and see if you can follow the > existing snapshot code to understand how it works. Once you feel like you > have a good graps of that email me directly and we'll talk. Kirk and I > discussed ways that we could speed it up dramatically by doing > copy-on-write of the cgs in the allocation functions. This would take > care of the considerable delay that is incurred when making a snapshot. > > One good first project that would introduce you somewhat to the process of > kernel programming would be to add timing instrumentation to the various > stages of building a snapshot. This way you can prove where the delay > happens. Then you would be familiar with using timers, building custom > kernels, and a little bit of the snapshot code. > > Cheers, > Jeff I would love to see the speedup work done on taking snapshots, and Jeff's suggested approach to getting started on that project is excellent. However it is not a simple or easy project. As such you might find yourself getting frustrated. But if you feel up to the task, please do try it out. An alternative and somewhat simpler project which I would also like to see done would be to take a set of snapshots and instead of presenting them as a separate tree would be to provide them in a .snapshot directory located in each directory of the live filesystem (as done by network appliance and I believe ZFS). The project is simpler because most of the code already exists in the union filesystem. This project would start from the existing union filesystem code using it to place each snaphot "under" the live filesystem, then fiddling with the name lookup function to make it place each file in a .snapshot subdirectory under each live directory rather than by putting each file in the live directory itself (where it would be obscured by the live file of the same name). Kirk McKusick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201001020621.o026LXac038508>