Interesting that you mention the multitude of file systems because
I was very surprised to see NILFS being promoted in the latest Linux
Magazine but no mention of the other more important file systems
currently in work like UnionFS ChunkFS or ext4 so publisized.
I can say I was disapointed of the
Erik == Erik Mouw [EMAIL PROTECTED] writes:
Erik (sorry for the late reply, just got back from holiday)
Erik On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote:
As I mentioned in my Linux.conf.au presentation a year and a half ago,
the main use of Streams in Windows to date has been
On Thu, 5 Jul 2007 09:57:40 -0400
John Stoffel [EMAIL PROTECTED] wrote:
Erik == Erik Mouw [EMAIL PROTECTED] writes:
Erik (sorry for the late reply, just got back from holiday)
Erik On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote:
As I mentioned in my Linux.conf.au
On Wed, Jul 04, 2007 at 04:47:59PM -0400, Theodore Tso wrote:
On Wed, Jul 04, 2007 at 07:32:34PM +0200, Erik Mouw wrote:
(sorry for the late reply, just got back from holiday)
On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote:
As I mentioned in my Linux.conf.au presentation a
On Thu, Jul 05, 2007 at 09:57:40AM -0400, John Stoffel wrote:
Erik == Erik Mouw [EMAIL PROTECTED] writes:
Erik The only valid use of Streams in Windows I've seen was a virus
Erik checker that stored a hash of the file in a separate
Erik stream. Checking a file was a matter of rehashing it and
On Wed, Jul 04, 2007 at 07:32:34PM +0200, Erik Mouw wrote:
(sorry for the late reply, just got back from holiday)
On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote:
As I mentioned in my Linux.conf.au presentation a year and a half ago,
the main use of Streams in Windows to date
On Mittwoch, 20. Juni 2007, H. Peter Anvin wrote:
Alan Cox wrote:
POSIX is very
clear about what is acceptable as magic in a pathname, and the unix spec
even more so. The NetApp approach recognizes two important things
1. Old version access is the oddity not the norm
2. Standards
On Tue, 2007-06-19 at 20:12 +0100, Jack Stone wrote:
H. Peter Anvin wrote:
Chris Snook wrote:
I pointed out NetApp's .snapshot directories because that's a method
that uses legal path character, but doesn't break anything. With this
method, userspace tools will have to be taught that :
The directory is quite visible with a standard 'ls -a'. Instead,
they simply mark it as a separate volume/filesystem: i.e. the fsid
differs when you call stat(). The whole thing ends up acting rather like
our bind mounts.
Hmm. So it breaks user space quite a bit. By break, I mean uses that
Bryan Henderson wrote:
The directory is quite visible with a standard 'ls -a'. Instead,
they simply mark it as a separate volume/filesystem: i.e. the fsid
differs when you call stat(). The whole thing ends up acting rather like
our bind mounts.
Hmm. So it breaks user space quite a bit. By
Bryan Henderson wrote:
The directory is quite visible with a standard 'ls -a'. Instead,
they simply mark it as a separate volume/filesystem: i.e. the fsid
differs when you call stat(). The whole thing ends up acting rather like
our bind mounts.
Hmm. So it breaks user space quite a bit. By
On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote:
The main difference appears to be the potential size. Both extended
attributes and forks allow for extra data that I neither want or need.
But once the extra space is large enough to hide a rootkit in, it
becomes a security problem
On Mon, Jun 18, 2007 at 03:48:15PM -0700, Jeremy Allison wrote:
Did you ever code up forkdepot ? Just wondering ?
There is a partial implementation lieing around somewhere, but there
were a number of problems we ran into that were discussed in the
slidedeck. Basically, if the only program
Kyle Moffett wrote:
On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
The question remains is where to implement versioning: directly in
individual filesystems or in the vfs code so all filesystems can use it?
Or not in the kernel at all. I've been doing versioning of the types
I
On Mon, Jun 18, 2007 at 11:10:42PM -0400, Kyle Moffett wrote:
On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
The question remains is where to implement versioning: directly in
individual filesystems or in the vfs code so all filesystems can use it?
Or not in the kernel at all. I've
On 6/19/07, Kyle Moffett [EMAIL PROTECTED] wrote:
What I think would be particularly interesting in this domain is
something similar in concept to GIT, except in a file-system:
perhaps stating the blindingly obvious, but there was an early
implementation of a FUSE-based gitfs --
On Tue, Jun 19, 2007 at 03:05:07AM -0400, Theodore Tso wrote:
There is a partial implementation lieing around somewhere, but there
were a number of problems we ran into that were discussed in the
slidedeck. Basically, if the only program accessing the files
containing forks was the Samba
Jeremy Allison wrote:
I'm not talking WinFS, I'm talking streams. Streams are already
being used (mainly by malware writers of course - but hey, don't
you want full compatibility ? :-).
Reminds me of the Linux Journal (I believe?) article which did
viruses-on-Wine compatibility
Kyle Moffett wrote:
On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
The question remains is where to implement versioning: directly in
individual filesystems or in the vfs code so all filesystems can
use it?
Or not in the kernel at all. I've been doing versioning of the
types I
Jack Stone wrote:
Chris Snook wrote:
The underlying internal implementation of something like this wouldn't
be all that hard on many filesystems, but it's the interface that's the
problem. The ':' character is a perfectly legal filename character, so
doing it that way would break things.
But
Chris Snook wrote:
But what you're talking about *will* break userspace. If I do an ls in
a directory, and get pages upon pages of versions of just one file,
that's broken. If I tar up a directory and get a tarball that's
hundreds of times larger than it should be, that's broken. If you
Chris Snook wrote:
I pointed out NetApp's .snapshot directories because that's a method
that uses legal path character, but doesn't break anything. With this
method, userspace tools will have to be taught that : is suddenly a
special character.
Not to mention that the character historically
H. Peter Anvin wrote:
Chris Snook wrote:
I pointed out NetApp's .snapshot directories because that's a method
that uses legal path character, but doesn't break anything. With this
method, userspace tools will have to be taught that : is suddenly a
special character.
Not to mention that
Jack Stone wrote:
But that would cause havoc with shells which use ; to seperate commands.
Using ; would defiantly break userspace
Not really. It's just a bit awkward to use, but so's the whole concept.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel
H. Peter Anvin wrote:
Jack Stone wrote:
But that would cause havoc with shells which use ; to seperate commands.
Using ; would defiantly break userspace
Not really. It's just a bit awkward to use, but so's the whole concept.
I think we can all agree on that after this thread but I still
Jack Stone wrote:
Chris Snook wrote:
But what you're talking about *will* break userspace. If I do an ls in
a directory, and get pages upon pages of versions of just one file,
that's broken. If I tar up a directory and get a tarball that's
hundreds of times larger than it should be, that's
Chris Snook wrote:
Jack Stone wrote:
The idea was that if you did an ls you would get the latest version of
the file without the :revision_num. The only visible version would be
the latest version, i.e. the current system would not change. The idea
was that it would only show earlier versions
Chris Snook wrote:
Jack Stone wrote:
H. Peter Anvin wrote:
Chris Snook wrote:
I pointed out NetApp's .snapshot directories because that's a method
that uses legal path character, but doesn't break anything. With this
method, userspace tools will have to be taught that : is suddenly a
Jack Stone wrote:
Chris Snook wrote:
Jack Stone wrote:
The idea was that if you did an ls you would get the latest version of
the file without the :revision_num. The only visible version would be
the latest version, i.e. the current system would not change. The idea
was that it would only show
Chris Snook wrote:
Okay, so now you have to modify ls, cp, tar, and thousands of other
applications to be aware of the versioning, otherwise you can't use it.
Please don't get hung up on the interface. This is a really cool
feature that will require some serious engineering work to make it
Jack Stone wrote:
Chris Snook wrote:
Jack Stone wrote:
H. Peter Anvin wrote:
Chris Snook wrote:
I pointed out NetApp's .snapshot directories because that's a method
that uses legal path character, but doesn't break anything. With this
method, userspace tools will have to be taught that : is
Jack == Jack Stone [EMAIL PROTECTED] writes:
Jack The whole idea of the file system is that it wouldn't return the
Jack file in the file listing. The user would have to know that the
Jack file system was versioning to access the older versions as they
Jack would explicitly have to request them.
John Stoffel wrote:
Jack == Jack Stone [EMAIL PROTECTED] writes:
Jack The whole idea of the file system is that it wouldn't return the
Jack file in the file listing. The user would have to know that the
Jack file system was versioning to access the older versions as they
Jack would
Matthew On Tue, Jun 19, 2007 at 04:34:42PM -0400, John Stoffel wrote:
Jack == Jack Stone [EMAIL PROTECTED] writes:
Jack The whole idea of the file system is that it wouldn't return the
Jack file in the file listing. The user would have to know that the
Jack file system was versioning to
On Tue, 19 Jun 2007, Lennart Sorensen wrote:
On Tue, Jun 19, 2007 at 02:03:07PM -0400, Chris Snook wrote:
I pointed out NetApp's .snapshot directories because that's a method that
uses legal path character, but doesn't break anything. With this method,
userspace tools will have to be taught
Alan Cox wrote:
Yes but tdskb:foo.mac[1013,1013,frob];4 is *not* elegant.
I think describing VMS pathname syntax as not elegant is kind of like
describing George W. Bush as not a genius.
POSIX is very
clear about what is acceptable as magic in a pathname, and the unix spec
even more so.
On Tue, Jun 19, 2007 at 03:07:40PM -0700, [EMAIL PROTECTED] wrote:
since anything starting with . is considered a 'hidden' file per *nix
tradition it's ignored by many programs and optionally ignored by most
others (and anything that doesn't ignore . files when presending files to
the user
On Tue, Jun 19, 2007 at 03:13:33PM -0700, H. Peter Anvin wrote:
[EMAIL PROTECTED] wrote:
the only trouble I ever had with the .snapshot approach is when tar or
find would decend down into the .snapshot when I didn't really intend
for it to do so.
Netapp optionally made .snapshot
Jan Harkes wrote:
Still, anything that depends on increasing the length of file or path
names to refer to different versions will encounter problems for long
file names and deep paths because there is an upper limit on file and
path name lengths.
Then you have the Solaris variant -- rely
We don't need a new special character for every
new feature. We've got one, and it's flexible enough to do what you
want,
as proven by NetApp's extremely successful implementation.
I don't know NetApp's implementation, but I assume it is more than just a
choice of special character. If
On Tue, 2007-06-19 at 16:35 -0700, Bryan Henderson wrote:
We don't need a new special character for every
new feature. We've got one, and it's flexible enough to do what you
want,
as proven by NetApp's extremely successful implementation.
I don't know NetApp's implementation, but I
On Jun 19, 2007, at 03:58:57, Bron Gondwana wrote:
On Mon, Jun 18, 2007 at 11:10:42PM -0400, Kyle Moffett wrote:
On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
The question remains is where to implement versioning: directly
in individual filesystems or in the vfs code so all filesystems
Trond Myklebust wrote:
I assume NetApp flags the directory specially so that a POSIX directory
read doesn't get it. I've seen that done elsewhere.
No. The directory is quite visible with a standard 'ls -a'. Instead,
they simply mark it as a separate volume/filesystem: i.e. the fsid
On Jun 16, 2007 16:53 +0200, Jörn Engel wrote:
On Fri, 15 June 2007 15:51:07 -0700, alan wrote:
Thus, in the end it turns out that this stuff is better handled by
explicit version-control systems (which require explicit operations to
manage revisions) and atomic snapshots (for backup.)
Andreas Dilger wrote:
Too bad everyone is spending time on 10 similar-but-slightly-different
filesystems. This will likely end up with a bunch of filesystems that
implement some easy subset of features, but will not get polished for
users or have a full set of features implemented (e.g. ACL,
On Mon, 18 June 2007 03:45:24 -0600, Andreas Dilger wrote:
Too bad everyone is spending time on 10 similar-but-slightly-different
filesystems. This will likely end up with a bunch of filesystems that
implement some easy subset of features, but will not get polished for
users or have a full
On Mon, Jun 18, 2007 at 03:45:24AM -0600, Andreas Dilger wrote:
Too bad everyone is spending time on 10 similar-but-slightly-different
filesystems. This will likely end up with a bunch of filesystems that
implement some easy subset of features, but will not get polished for
users or have a
On Mon, Jun 18, 2007 at 03:45:24AM -0600, Andreas Dilger wrote:
Too bad everyone is spending time on 10 similar-but-slightly-different
filesystems. This will likely end up with a bunch of filesystems that
implement some easy subset of features, but will not get polished for
users or have a
Part of the problem is that whenever you modify a file
is ill-defined, or rather, if you were to take the literal meaning of it
you'd end up with an unmanageable number of revisions.
Let me expand on that. Do you want to save a revision every time the user
types in an editor? Every time he
On Mon, 18 Jun 2007, Theodore Tso wrote:
On Mon, Jun 18, 2007 at 03:45:24AM -0600, Andreas Dilger wrote:
Too bad everyone is spending time on 10 similar-but-slightly-different
filesystems. This will likely end up with a bunch of filesystems that
implement some easy subset of features, but
Bryan Henderson wrote:
Part of the problem is that whenever you modify a file
is ill-defined, or rather, if you were to take the literal meaning of it
you'd end up with an unmanageable number of revisions.
Let me expand on that. Do you want to save a revision every time the user
types in
Jack Stone wrote:
Later, I discovered what I think are superior alternatives: RCS-style
version management on top of the filesystem, and automatic versioning
based on time instead of count of modifications. For example, make a
copy of every changed file every hour and keep it for a day
On Mon, Jun 18, 2007 at 09:16:30AM -0700, alan wrote:
I just wish that people would learn from the mistakes of others. The
MacOS is a prime example of why you do not want to use a forked
filesystem, yet some people still seem to think it is a good idea.
(Forked filesystems tend to be
Theodore Tso wrote:
As I mentioned in my Linux.conf.au presentation a year and a half ago,
the main use of Streams in Windows to date has been for system
crackers to hide trojan horse code and rootkits so that system
administrators couldn't find them. :-)
But... that's an essential
On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote:
On Mon, Jun 18, 2007 at 09:16:30AM -0700, alan wrote:
I just wish that people would learn from the mistakes of others. The
MacOS is a prime example of why you do not want to use a forked
filesystem, yet some people still
The question remains is where to implement versioning: directly in
individual filesystems or in the vfs code so all filesystems can use it?
Or not in the kernel at all. I've been doing versioning of the types I
described for years with user space code and I don't remember feeling that
I
On Mon, Jun 18, 2007 at 10:33:42AM -0700, Jeremy Allison wrote:
Yeah, ok - but do you have to rub my nose in it every chance you get ?
:-) :-).
Well, I just want to make sure people know that Samba isn't asking for
it any more, and I don't know of any current requests outstanding from
any
On Mon, Jun 18, 2007 at 04:30:33PM -0400, Theodore Tso wrote:
Well, I just want to make sure people know that Samba isn't asking for
it any more, and I don't know of any current requests outstanding from
any of the userspace projects. So there's no one we need to ship off
to the re-education
alan [EMAIL PROTECTED] wrote:
I just wish that people would learn from the mistakes of others. The
MacOS is a prime example of why you do not want to use a forked
filesystem, yet some people still seem to think it is a good idea.
(Forked filesystems tend to be fragile and do not play well
On Mon, 18 Jun 2007, Bodo Eggert wrote:
alan [EMAIL PROTECTED] wrote:
I just wish that people would learn from the mistakes of others. The
MacOS is a prime example of why you do not want to use a forked
filesystem, yet some people still seem to think it is a good idea.
(Forked filesystems
alan wrote:
On Mon, 18 Jun 2007, Bodo Eggert wrote:
alan [EMAIL PROTECTED] wrote:
I just wish that people would learn from the mistakes of others. The
MacOS is a prime example of why you do not want to use a forked
filesystem, yet some people still seem to think it is a good idea.
On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote:
And that makes them different from extended attributes, how?
Streams on systems that support them allow lseek and are
accessed by fd's. EA's are always a blob of data, read/written
in their entirity.
Jeremy.
-
To unsubscribe from
On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote:
And that makes them different from extended attributes, how?
Both of these really are nothing but ad hocky syntactic sugar for
directories, sometimes combined with in-filesystem support for small
data items.
There's a good
On Mon, 18 June 2007 18:10:21 -0400, Theodore Tso wrote:
On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote:
And that makes them different from extended attributes, how?
Both of these really are nothing but ad hocky syntactic sugar for
directories, sometimes combined with
On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote:
Pointless here means that _I_ don't see the point. Maybe there are
valid uses for extended attributes. If there are, noone has explained
them to me yet.
Samba uses them to store DOS'ism's that you don't want in your
POSIX
On Mon, 18 Jun 2007, H. Peter Anvin wrote:
alan wrote:
On Mon, 18 Jun 2007, Bodo Eggert wrote:
alan [EMAIL PROTECTED] wrote:
I just wish that people would learn from the mistakes of others. The
MacOS is a prime example of why you do not want to use a forked
filesystem, yet some people
On Mon, Jun 18, 2007 at 06:10:21PM -0400, Theodore Tso wrote:
On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote:
And that makes them different from extended attributes, how?
Both of these really are nothing but ad hocky syntactic sugar for
directories, sometimes combined
On Tue, 19 Jun 2007, Jörn Engel wrote:
On Mon, 18 June 2007 18:10:21 -0400, Theodore Tso wrote:
On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote:
And that makes them different from extended attributes, how?
Both of these really are nothing but ad hocky syntactic sugar for
On Mon, Jun 18, 2007 at 11:32:38AM -0400, Chris Mason wrote:
On Mon, Jun 18, 2007 at 03:45:24AM -0600, Andreas Dilger wrote:
Too bad everyone is spending time on 10 similar-but-slightly-different
filesystems. This will likely end up with a bunch of filesystems that
implement some easy
On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote:
Pointless here means that _I_ don't see the point. Maybe there are
valid uses for extended attributes. If there are, noone has explained
them to me yet.
The users of extended attributes that I've dealt with are ACL support
and
On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
The question remains is where to implement versioning: directly in
individual filesystems or in the vfs code so all filesystems can
use it?
Or not in the kernel at all. I've been doing versioning of the
types I described for years with
On Jun 18, 2007, at 17:24:23, Brad Boyer wrote:
On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote:
Pointless here means that _I_ don't see the point. Maybe there
are valid uses for extended attributes. If there are, noone has
explained them to me yet.
The users of extended
On Sat, Jun 16, 2007 at 11:17:58PM +0100, Alan Cox wrote:
(Vax/VMS System Software Handbook)
(TOPS-20 User's Manual)
Also Files/11
And don't forget the really ground breaking work (for the
time) done by the Xanadu folk.
-
To unsubscribe from this list: send the line unsubscribe
alan wrote:
On Fri, 15 Jun 2007, H. Peter Anvin wrote:
This is one of those things that seems like a good idea, but frequently
ends up short. Part of the problem is that whenever you modify a file
is ill-defined, or rather, if you were to take the literal meaning of it
you'd end up with an
Chris Snook wrote:
The underlying internal implementation of something like this wouldn't
be all that hard on many filesystems, but it's the interface that's the
problem. The ':' character is a perfectly legal filename character, so
doing it that way would break things.
But to work without
This already exists -- it just not open sourced, and you could spend
years trying to create it. Trust me, once you start dealing with the
distributed issues with this, its gets very complex. I am not meaning
to discourage you, but there are patents already filed on this on
Linux.So you
Jeffrey V. Merkey wrote:
This already exists -- it just not open sourced, and you could spend
years trying to create it. Trust me, once you start dealing with the
distributed issues with this, its gets very complex. I am not meaning
to discourage you, but there are patents already filed
I reviewed your sample implementation, and it appears to infringe 3
patents already.You should do some research on this.
Are you able to tell us which areas of the code infringe existing patents?
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no
On Fri, 15 June 2007 15:51:07 -0700, alan wrote:
Thus, in the end it turns out that this stuff is better handled by
explicit version-control systems (which require explicit operations to
manage revisions) and atomic snapshots (for backup.)
ZFS is the cool new thing in that space. Too bad
Jeffrey V. Merkey wrote:
When you get into the recycling issues with storage, the patents come
into play. Also, using the file name to reference revisions is already
the subject of a patent previously filed (I no longer own the patent, I
sold them to Canopy). There is a third one about to be
http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENGDBSELECT=PCTSERVER_TYPE=19SORT=1211506-KEYTYPE_FIELD=256IDB=0IDOC=1205953C=10ELEMENT_SET=IA,WO,TTL-ENRESULT=1TOTAL=3START=1DISP=25FORM=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENGSEARCH_IA=US2005045566QUERY=%28IN%2fmerkey%29+
The last one was filed with
Alan Cox wrote:
http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENGDBSELECT=PCTSERVER_TYPE=19SORT=1211506-KEYTYPE_FIELD=256IDB=0IDOC=1205953C=10ELEMENT_SET=IA,WO,TTL-ENRESULT=1TOTAL=3START=1DISP=25FORM=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENGSEARCH_IA=US2005045566QUERY=%28IN%2fmerkey%29+
The last one
On Sat, Jun 16, 2007 at 02:03:49PM -0600, Jeffrey V. Merkey wrote:
Jan Harkes wrote:
implementation, just a high level description. Finally advising anyone
(who is not an actual patent lawyer that could correctly interpret the
language and scope of a patent) to go search out patents seems
Jan Harkes wrote:
Sites like portal.acm.org and citeseer.ist.psu.edu are good places to
find copies of these papers. They also provide links to other work that
either is cited by, or cites these papers which is a convenient way to
find other papers in this area.
Researching, designing and
DEC had versioning files systems 30 years ago. Any
patents on their style must certainly have expired
long ago.
Look at RSX-11 and other seventies era operating
systems.
This is ancient stuff.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to
(Vax/VMS System Software Handbook)
(TOPS-20 User's Manual)
Also Files/11
Basic versioning goes back to at least ITS
Not sure how old doing file versioning and hiding it away with a tool to
go rescue the stuff you blew away by mistake is, but Novell Netware 3
certainly did a good job on
Alan Cox wrote:
(Vax/VMS System Software Handbook)
(TOPS-20 User's Manual)
Also Files/11
Basic versioning goes back to at least ITS
Not sure how old doing file versioning and hiding it away with a tool to
go rescue the stuff you blew away by mistake is, but Novell Netware 3
certainly
Jeffrey V. Merkey wrote:
The trick in the NetWare 3 model was to segregate the directory
entries onto special reserved
4K directory blocks (128 byte dir records). When it came time to purge
storage after the file system filled, an entire 4K block and all
chains was deleted during block
I hope I got the CC list right. Apologies to anyone in didn't include
and anyone I shouldn't have included.
The basic idea is to include an idea from VMS that seems to be quite
useful: version numbers for files.
The idea is that whenever you modify a file the system saves it to na
new copy
Jack Stone wrote:
I hope I got the CC list right. Apologies to anyone in didn't include
and anyone I shouldn't have included.
The basic idea is to include an idea from VMS that seems to be quite
useful: version numbers for files.
The idea is that whenever you modify a file the system
Jack Stone wrote:
I hope I got the CC list right. Apologies to anyone in didn't include
and anyone I shouldn't have included.
The basic idea is to include an idea from VMS that seems to be quite
useful: version numbers for files.
The idea is that whenever you modify a file the system saves it
Jack Stone wrote:
I hope I got the CC list right. Apologies to anyone in didn't include
and anyone I shouldn't have included.
The basic idea is to include an idea from VMS that seems to be quite
useful: version numbers for files.
snip
have you looked into ext3cow? it allows you to take
On Fri, 15 Jun 2007, H. Peter Anvin wrote:
alan wrote:
ZFS is the cool new thing in that space. Too bad the license makes it
hard to incorporate it into the kernel. (I am one of those people that
believe that Linux should support EVERY file system, no matter how old
or obscure.)
I have
93 matches
Mail list logo
