Date: Fri, 3 Mar 2000 14:49:12 -0800 From: Brooks Davis <brooks@one-eyed-alien.net> To: Julian Elischer <julian@elischer.org> Cc: David Scheidt <dscheidt@enteract.com>, Michael Bacarella <mbac@nyct.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: Copy-on-write filesystem Message-ID: <20000303144912.B902@orion.ac.hmc.edu> In-Reply-To: <38C0312A.2781E494@elischer.org>; from julian@elischer.org on Fri, Mar 03, 2000 at 01:39:54PM -0800 References: <Pine.NEB.3.96.1000303145335.55794B-100000@shell-1.enteract.com> <38C0312A.2781E494@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 03, 2000 at 01:39:54PM -0800, Julian Elischer wrote: > David Scheidt wrote: > > > > On Fri, 3 Mar 2000, Michael Bacarella wrote: > > > > > Upon reading of Microsoft's fabulous innovations in the filesystem arena, > > > I started playing with some ideas of my own (not to be confused with > > > ORIGINAL ideas) > > > > > > Can someone tell me why copy-on-write filesystems would be bad? > > > > It wouldn't be. This is how NetApp do their .snapshot direcotries. I think > > they have some white papers on it on their website. It's very handy. > > Kirk McKusick is implementing a Copy-on write functionality > for UFS. It is used in conjunction with Soft updates to produce > snapshots. It's not what you asked for, but still relevant > I think. One problem with "Copy-on-write, when applied to > file copies is that you need to assign the blocks up front, even if you > don't copy the data, as otherwise you could run out of space > when the copy is actually needed. Don't holes already cause this problem? Admittly you are much more likely to run into it if cp doesn't result in block reservations. In any case, if you do prereserve the storage you should probably just make copying lazy so given sufficient quiet time the system will no longer have any COW'd pages. Unfortunaly I think this problem is likely to be a rehash of the memory over subscription flame-wars the pop up periodicly (if you don't know, DON'T ASK, read the archives.) The game has changed a bit though because disk is quite different from memory in terms of access characteristics and purpose. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000303144912.B902>