> > > > Imagine: cp file file2, file and file2 reference the same exact blocks,
> > > > but modified chunks of file2 would be given their own private blocks.
> > >
> > > This is not a microsoft innovation, actually, I believe it was a VMS
> > > innovation. It's called a generational filesystem.
> "Jim" == Jim Bryant <[EMAIL PROTECTED]> writes:
Jim> This is not a microsoft innovation, actually, I believe it
Jim> was a VMS innovation. It's called a generational filesystem.
Jim> the original is stored, and later generations of the file are
Jim> stored as diffs.
IIRC,
On Fri, 3 Mar 2000, Mike Smith wrote:
> > Actually, since this is copy-on-write, you do not need the block, until
> > you write. If you need to make a copy, it will be on a write system call
> > (possibly an inode update), just fail the write ENOSPC or whatever. Or am
> > I missing something si
> > > Imagine: cp file file2, file and file2 reference the same exact blocks,
> > > but modified chunks of file2 would be given their own private blocks.
> >
> > This is not a microsoft innovation, actually, I believe it was a VMS
> > innovation. It's called a generational filesystem. the origi
> > Imagine: cp file file2, file and file2 reference the same exact blocks,
> > but modified chunks of file2 would be given their own private blocks.
>
> This is not a microsoft innovation, actually, I believe it was a VMS
> innovation. It's called a generational filesystem. the original is
> s
In reply:
> On Fri, 3 Mar 2000, Michael Bacarella wrote:
>
> > Can someone tell me why copy-on-write filesystems would be bad?
>
> It's a good idea. Peter Braam and I have written a device (called memdev)
> for linux (sorry!) that implements a virtual-memory-backed copy-on-write
> block device (
In reply:
> Imagine: cp file file2, file and file2 reference the same exact blocks,
> but modified chunks of file2 would be given their own private blocks.
This is not a microsoft innovation, actually, I believe it was a VMS
innovation. It's called a generational filesystem. the original is
sto
:Swap? I thought we were talking about a copy-on-write filesystem
:i.e. disk block, not memory, or did I really miss something
:
:Brian Beattie| The only problem with
Where are you copy-on-writing to? Unbacked memory? No way that
would ever work, at least not for any
ock, until
> :you write. If you need to make a copy, it will be on a write system call
> :(possibly an inode update), just fail the write ENOSPC or whatever. Or am
> :I missing something simple here.
>
> The issue here is to ensure that you have sufficient swap.
Swap? I though
:> > 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.
:>
:> That's the only real drawback I've considered
> > No one will appreciate that happening to their "permanent" data,
> > especially if the OS decides that the best way to get out of debt is by
> > deleting a file :)
>
> Actually, since this is copy-on-write, you do not need the block, until
> you write. If you need to make a copy, it will be
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 w
On Fri, 3 Mar 2000, Michael Bacarella wrote:
>
> > > 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 us
> > 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
ommand 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 h
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
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
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?
>
> Imagin
:It's a good idea. Peter Braam and I have written a device (called memdev)
:for linux (sorry!) that implements a virtual-memory-backed copy-on-write
:block device (like the loopback device, but uses anon vm pages for store).
:
:It's pretty interesting. It's quite fast, and copy-on-write does seem
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 sourc
On Fri, 3 Mar 2000, Michael Bacarella wrote:
> Can someone tell me why copy-on-write filesystems would be bad?
It's a good idea. Peter Braam and I have written a device (called memdev)
for linux (sorry!) that implements a virtual-memory-backed copy-on-write
block device (like the loopback device
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?
Imagine: cp file file2, file and file2 reference the same exact blocks,
22 matches
Mail list logo
