Date: Fri, 3 Mar 2000 16:48:07 -0500 (EST) From: Michael Bacarella <mbac@bsd4.nyct.net> To: freebsd-hackers@FreeBSD.ORG Subject: VFS Change? (was: Re: Copy-on-write filesystem) Message-ID: <Pine.BSF.4.02A.10003031632440.28555-100000@bsd4.nyct.net> In-Reply-To: <Pine.LNX.4.21.0003031051250.22409-100000@shell1.aracnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Sounds very intriquing. The biggest problem I see, right away is fitting > it's use into a UNIX environment, were, file copies are made with the > write system call, making it impossible to implement for the general case. > You could certainly rewrite the "cp" command and that would get a majority > of cases, though it is hard to say how many. The answer would depend on > how the copies were made. I suspect that a large number of copies on most > systems are made by going to the original source (tar file, etc...), these > would not be helped by a copy-on-write filesystem. I originally started tossing around the idea as a copy-on-write symlink. Simply vanilla symlinks that made private copies of changes rather than writing through the links to the referenced file. The admin has much more control over it this way. I have no idea why I thought of COPY as an abstract filesystem method, when I clearly knew it copied files by open()'ing a new file and read()/write() old/new I probably thought of it being that way because that's how I would've implemented it. Ho hum. Usually, assuming UNIX does things the way that I probably would has a good success rate, which I will now discredit by stating the following: Objective Soapbox Is a COPY call in the VFS layer a bad idea? Copy is a rather common filesystem primitive, and the filesystem is free to do what it considers to be the best way to make a copy of a set of data, perhaps even supporting copy-on-write at this level, but practically, skipping the overhead of having an application do: while (read()) write(); To simply copy a file. I was lectured about something like that awhile ago, mentioning that FreeBSD isn't optimized for that. (syscall(); stuff; syscall(); repeat 50000 times) The filesystem knows how to do this, and since it can make assumptions about what's going to happen, it can probably optimize the cache being used. (Or at least provide far more reasonably hints to the OS about how to cache it, if caching isn't handled at the FS layer) -MB 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?Pine.BSF.4.02A.10003031632440.28555-100000>