Re: [PATCH] NFS: Make NFS root work again
On Sat, Jun 16, 2007 at 09:15:14AM -0700, Andrew Morton wrote: > On Thu, 07 Jun 2007 17:40:03 +0100 David Howells <[EMAIL PROTECTED]> wrote: > > Make NFS root work by creating a "/root" directory to satisfy the mount, > > otherwise the path lookup for the mount fails with ENOENT. > > > > Am still awaiting a proper description of this patch, please. > > What is not working, and how does this patch fix it? > > I am unaware of any open bug reports against NFS root. I've not had any problems with it during any of the -rc periods, for what it's worth. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
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 allocation for new files. The dir blocks were ordered by date -- oldest ones got purged first. The model worked very well until compression was added to the filesystem, then it started getting complex. I would be willing to help instrument the NetWare 3 model in this proposal on ext3, since this is a basic versioning model and would provide coverage for 99% of the folks needing this capability. I am available for questions. Jeff I resigned as Chief Scientist of Solera Networks May 8 this year -- mostly because I was not allowed to have any freedom, including working on free Linux projects. This went on for almost 4 years (since 2003). Now that I am independent again, I can work on stuff like this again. I started a new company with John Noorda (Ray Noorda's oldest son) who runs Canopy now. That's my current status. I am an owner and entrepeneur again. So I have a lot of free time and will from now on. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
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 did a good job on that one 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 allocation for new files. The dir blocks were ordered by date -- oldest ones got purged first. The model worked very well until compression was added to the filesystem, then it started getting complex. I would be willing to help instrument the NetWare 3 model in this proposal on ext3, since this is a basic versioning model and would provide coverage for 99% of the folks needing this capability. I am available for questions. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
> (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 that one - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
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 implementing such systems is a lot of fun, > admittedly often more fun than long term debugging and/or maintaining, > but that is life. Don't get too upset if the end result cannot be > included in the main kernel. Just start over from scratch, you may just > end up with an even better design the second time around. Thank you very much for the info and the advice. I would also like to thank everyone for the help and enchouragement that they have given to me. Jack - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
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 pretty > >bad advice. That can only result in not even attempting to research some > >potentially new and innovative approach. > > > >Researching prior published work in the area is considerably more > >helpful. Especially when something is complex beyond belief it has > >probably attracted various researchers over time and there are most > >likely various different solutions that have been explored previously. > >Such existing work can form a good basis for further work. > > 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 issued. Congratulations on obtaining those patents, I hope they will be used wisely. I am however not a patent lawyer and as such in no position to evaluate their claims. As a more useful response, the original poster may want to look at some of the prior work in this area, I just picked a couple, (Cedar File System from Xerox PARC) A Caching File System for a Programmer's Workstation (1985) Michael D. Schroeder, David K. Gifford, Roger M. Needham (Vax/VMS System Software Handbook) (TOPS-20 User's Manual) (Plan 9 (file system)) Plan 9 from Bell Labs (1990) Rob Pike, Dave Presotto, Sean Dorward, Bob Flandrena, Ken Thompson, Howard Trickey, Phil Winterbottom (Elephant File System) Elephant: The File System that Never Forgets (1999) Douglas J. Santry, Michael J. Feeley, Norman C. Hutchinson Workshop on Hot Topics in Operating Systems Deciding when to forget in the Elephant file system (1999) Douglas S. Santry, Michael J. Feeley, Norman C. Hutchinson, Alistair C. Veitch, Ross W. Carton, Jacob Otir (Ext3Cow) Ext3cow: The Design, Implementation, and Analysis of Metadata for a Time-Shifting File System (2003) Zachary N. J. Peterson, Randal C. Burns 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 implementing such systems is a lot of fun, admittedly often more fun than long term debugging and/or maintaining, but that is life. Don't get too upset if the end result cannot be included in the main kernel. Just start over from scratch, you may just end up with an even better design the second time around. Jan - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
Alan Cox wrote: http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENG&DBSELECT=PCT&SERVER_TYPE=19&SORT=1211506-KEY&TYPE_FIELD=256&IDB=0&IDOC=1205953&C=10&ELEMENT_SET=IA,WO,TTL-EN&RESULT=1&TOTAL=3&START=1&DISP=25&FORM=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENG&SEARCH_IA=US2005045566&QUERY=%28IN%2fmerkey%29+ The last one was filed with WIPO and has international protection, UK included. Nope. EU and UK law does not recognize software as patentable. See the caselaw. Thanks for clarifying Alan, I was uncertain about current patent laws in the UK and abroad. I know this area has undergone considerable debate and changes recently, and I have not been keeping up with all of it. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
> http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENG&DBSELECT=PCT&SERVER_TYPE=19&SORT=1211506-KEY&TYPE_FIELD=256&IDB=0&IDOC=1205953&C=10&ELEMENT_SET=IA,WO,TTL-EN&RESULT=1&TOTAL=3&START=1&DISP=25&FORM=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENG&SEARCH_IA=US2005045566&QUERY=%28IN%2fmerkey%29+ > > The last one was filed with WIPO and has international protection, UK > included. Nope. EU and UK law does not recognize software as patentable. See the caselaw. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
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 issued. > > The patents are: > * > 6,862,609 > **6,795,895 > > and this one about to be issued: > > http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENG&DBSELECT=PCT&SERVER_TYPE=19&SORT=1211506-KEY&TYPE_FIELD=256&IDB=0&IDOC=1205953&C=10&ELEMENT_SET=IA,WO,TTL-EN&RESULT=1&TOTAL=3&START=1&DISP=25&FORM=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENG&SEARCH_IA=US2005045566&QUERY=%28IN%2fmerkey%29+ > > > The last one was filed with WIPO and has international protection, UK > included. I have no idea about patents so if anyone could point me in the right direction I would be most obliged Jack - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
Jan Harkes wrote: On Sat, Jun 16, 2007 at 04:12:14AM -0600, Jeffrey V. Merkey wrote: Jeffrey V. Merkey wrote: over). There's also another patent filed as well. It's a noble effort to do a free version, but be aware there's some big guns with patents out there already, not to mention doing this is complex beyond belief. I reviewed your sample implementation, and it appears to infringe 3 patents already.You should do some research on this. First of all, you are responding to someone in the UK, I thought they didn't even have software patents over there. Second, I didn't see any 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 pretty bad advice. That can only result in not even attempting to research some potentially new and innovative approach. Researching prior published work in the area is considerably more helpful. Especially when something is complex beyond belief it has probably attracted various researchers over time and there are most likely various different solutions that have been explored previously. Such existing work can form a good basis for further work. Finally, even if there are patents they could be too limited in scope, overly broad, can be invalidated due to prior art. It may also be possible that a patent holder has no problem granting a royalty free license for a GPL licensed implementation. Jan 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 issued. The patents are: * 6,862,609 **6,795,895 and this one about to be issued: http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENG&DBSELECT=PCT&SERVER_TYPE=19&SORT=1211506-KEY&TYPE_FIELD=256&IDB=0&IDOC=1205953&C=10&ELEMENT_SET=IA,WO,TTL-EN&RESULT=1&TOTAL=3&START=1&DISP=25&FORM=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENG&SEARCH_IA=US2005045566&QUERY=%28IN%2fmerkey%29+ The last one was filed with WIPO and has international protection, UK included. Jeff * Jeff - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
Mark Williamson wrote: 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? Yes. Jeff Cheers, Mark - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
On Sat, Jun 16, 2007 at 04:12:14AM -0600, Jeffrey V. Merkey wrote: > Jeffrey V. Merkey wrote: > >over). There's also another patent filed as well. It's a noble > >effort to do a free version, but be aware there's some big guns with > >patents out there already, not to mention doing this is complex beyond > >belief. > > I reviewed your sample implementation, and it appears to infringe 3 > patents already.You should do some research on this. First of all, you are responding to someone in the UK, I thought they didn't even have software patents over there. Second, I didn't see any 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 pretty bad advice. That can only result in not even attempting to research some potentially new and innovative approach. Researching prior published work in the area is considerably more helpful. Especially when something is complex beyond belief it has probably attracted various researchers over time and there are most likely various different solutions that have been explored previously. Such existing work can form a good basis for further work. Finally, even if there are patents they could be too limited in scope, overly broad, can be invalidated due to prior art. It may also be possible that a patent holder has no problem granting a royalty free license for a GPL licensed implementation. Jan - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NFS: Make NFS root work again
On Sat, 2007-06-16 at 09:15 -0700, Andrew Morton wrote:
> On Thu, 07 Jun 2007 17:40:03 +0100 David Howells <[EMAIL PROTECTED]> wrote:
>
> > Make NFS root work by creating a "/root" directory to satisfy the mount,
> > otherwise the path lookup for the mount fails with ENOENT.
> >
> > Signed-off-by: David Howells <[EMAIL PROTECTED]>
> > ---
> >
> > init/do_mounts.c |5 -
> > 1 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/init/do_mounts.c b/init/do_mounts.c
> > index 46fe407..967b852 100644
> > --- a/init/do_mounts.c
> > +++ b/init/do_mounts.c
> > @@ -270,7 +270,10 @@ static void __init get_fs_names(char *page)
> >
> > static int __init do_mount_root(char *name, char *fs, int flags, void
> > *data)
> > {
> > - int err = sys_mount(name, "/root", fs, flags, data);
> > + int err;
> > +
> > + sys_mkdir("/root", 0755);
> > + err = sys_mount(name, "/root", fs, flags, data);
> > if (err)
> > return err;
>
> Am still awaiting a proper description of this patch, please.
>
> What is not working, and how does this patch fix it?
>
> I am unaware of any open bug reports against NFS root.
I'm confused too. We never used to require that the kernel create a
special /root directory. What changed, and when?
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Sat, Jun 16, 2007 at 01:09:06AM -0700, [EMAIL PROTECTED] wrote: > On Fri, 15 Jun 2007, Greg KH wrote: > > >>> Usually you don't do that by doing a 'mv' otherwise you are almost > >>> guaranteed stale and mixed up content for some period of time, not to > >>> mention the issues surrounding paths that might be messed up. > >> > >> on the contrary, useing 'mv' is by far the cleanest way to do this. > >> > >> mv htdocs htdocs.old;mv htdocs.new htdocs > >> > >> this makes two atomic changes to the filesystem, but can generate > >> thousands > >> to millions of permission changes as a result. > > > > I agree, and yet, somehow, SELinux today handles this just fine, right? > > :) > > no it doesn't, SELinux as-is should take no action when the above command is > run, but SELinux implementing path-based permissions will have to relabel > every file or directory in both trees. Agreed. > > Let's worry about speed issues later on when a working implementation is > > produced, I'm still looking for the logical reason a system like this > > can not work properly based on the expected AA interface to users. > > if you are willing to live with the race conditions from the slow > (re)labeling and write the software to scan the entire system to figure out > the right policies (and then use inotify to watch the entire system for > changes and (re)label the appropriate files) and accept that you can't get > any granular security for filesystems that don't nativly support it you > could make SELinux behave like AA. You make it sound like such a pretty picture :) Anyway, I don't think there are "race conditions", just a bit of a delay at times for situations that are not common or "normal operations". And as I think the speed issues can be drasticly reduced, I don't think that's a really big deal just yet. I'm trying to determine if there's any logical reason why we can't do this and have yet to see proof of that. > but why should they be required to? are you saying that the LSM hooks are > not a valid API and should be removed with all future security modules being > based on SELinux? Woah, that's a huge logical jump that I am not willing to make at this point in time. The reason I am proposing this for AA is due to the impeadance between the AA model and how the kernel internally works. A number of core kernel VFS developers have objected to the AA code and changes because of this problem and me and Pavel are here working to try to resolve this in a way that is acceptable to everyone involved (kernel developers and AA developers and AA end users.) I'll leave the whole "LSM should be just replaced with SELinux" discussion for later, as it is not relevant to this current topic at all. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NFS: Make NFS root work again
On Thu, 07 Jun 2007 17:40:03 +0100 David Howells <[EMAIL PROTECTED]> wrote:
> Make NFS root work by creating a "/root" directory to satisfy the mount,
> otherwise the path lookup for the mount fails with ENOENT.
>
> Signed-off-by: David Howells <[EMAIL PROTECTED]>
> ---
>
> init/do_mounts.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/init/do_mounts.c b/init/do_mounts.c
> index 46fe407..967b852 100644
> --- a/init/do_mounts.c
> +++ b/init/do_mounts.c
> @@ -270,7 +270,10 @@ static void __init get_fs_names(char *page)
>
> static int __init do_mount_root(char *name, char *fs, int flags, void *data)
> {
> - int err = sys_mount(name, "/root", fs, flags, data);
> + int err;
> +
> + sys_mkdir("/root", 0755);
> + err = sys_mount(name, "/root", fs, flags, data);
> if (err)
> return err;
Am still awaiting a proper description of this patch, please.
What is not working, and how does this patch fix it?
I am unaware of any open bug reports against NFS root.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
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 the license makes it > hard to incorporate it into the kernel. It may be the coolest, but there are others as well. Btrfs looks good, nilfs finally has a cleaner and may be worth a try, logfs will get snapshots sooner or later. Heck, even my crusty old cowlinks can be viewed as snapshots. If one has spare cycles to waste, working on one of those makes more sense than implementing file versioning. Jörn -- "Security vulnerabilities are here to stay." -- Scott Culp, Manager of the Microsoft Security Response Center, 2001 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
> 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 pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS
Chris Mason wrote: > Strange, these numbers are not quite what I was expecting ;) Could you > please post your fio job files? Also, how much ram does the machine > have? Only writing doesn't seem like enough to fill the ram. > > -chris > > Sure: > [global] > directory=/mnt/temp/default > filename=testfile > size=300m > randrepeat=1 > overwrite=1 > end_fsync=1 > > [job1] > description="sequ. read" > rw=read > > [job2] > stonewall > description="rand. write" > rw=randwrite > > [job3] > stonewall > description="sequ. read" > rw=read I have 1.5 GB RAM. I can easily rerun the tests with modified jobs, just tell me how to modify it florian - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
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 on this on Linux.So you need to consider these as well, and there are several folks who are already doing this or have done it. If it goes into Microsoft endorsed cross licensed Linuxes It may be ok (Vertias sold this capability to Microsoft already, about 12 patents there to worry over). There's also another patent filed as well. It's a noble effort to do a free version, but be aware there's some big guns with patents out there already, not to mention doing this is complex beyond belief. Anyway good luck. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ I reviewed your sample implementation, and it appears to infringe 3 patents already.You should do some research on this. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
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 need to consider these as well, and there are several folks who are already doing this or have done it. If it goes into Microsoft endorsed cross licensed Linuxes It may be ok (Vertias sold this capability to Microsoft already, about 12 patents there to worry over). There's also another patent filed as well. It's a noble effort to do a free version, but be aware there's some big guns with patents out there already, not to mention doing this is complex beyond belief. Anyway good luck. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
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 breaking userspace it would need to be a character that would pass through any path checking routines, ie be a legal path character. > I think NetApp more or less got the interface right by putting a > .snapshot directory in each directory, with time-versioned > subdirectories each containing snapshots of that directory's contents > at those points in time. It keeps the backups under the same > hierarchy as the original files, to avoid permissions headaches, > it's accessible over NFS without modifying the client at all, > and it's hidden just enough to make it hard for users to do something > stupid. My personal implementation idea was to store lots of files for the form file:revision_number (I'll keep using that until somebody sugests something better) on the file system itself, with a hard link form the latest version to file (this is probably not a major imporvement and having the hard link coudl make it hard to implement deltas). This could mean no changes to the file system itself (except maybe a flag to say its versioned). The kernel would then do the translation to find the correct file, and would only show the latest version to userapps not requesting a specific version. > If you want to do something like this (and it's generally not a bad > idea), make sure you do it in a way that's not going to change the > behavior seen by existing applications, and that is accessible to > unmodified remote clients. Hidden .snapshot directories are one way, a > parallel /backup filesystem could be another, whatever. If you break > existing apps, I won't touch it with a ten foot pole. The whole interface would be designed to give existing behavior as default for two reasons: users are used to opening a file and getting the latest version and not to break userspace. I personally wouldn't touch this either if it broke userspace. The only userspace change would be the addition of tools to manage the revisions etc. Userspace could later upgrade to take advantage of the new functionality but I cannot see the worth in breaking it. For an example of a working implementation see: http://www.o3one.org/filesystem.html Jack - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
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 unmanageable number of revisions. > > And no drive space. > One of the key points of the implementation would have to be the ability to delete old revisions without affecting the subsequent revisions. This would allow people to keep the number of revisions down. Also if each revision is in effect a patch on the last revision it could cut down the disk space required to store them, or if that takes to long to read a file then have every tenth version (0,10,20,30...not the tenth versions I know but easier to read) as a full version of the file which all future versions are changed off. >> Furthermore, it turns out that often relationships between files are >> more important. > > And there are files that are not important at all. > > Would you save every temp file? To be meaningful you would need to know > the process they were tied to in many cases. I hadn't considered that but I did think that you could remove the old revisions of a file at some configurable time after. This would allow recovery in case of accidental deletion but should keep the disk space usage down. >> 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.) Possibly but if I use it to manage my entire system (ie as a package manager) then the system would likely explode if I tryed to update or remove a key package whilst the system was running. With the kernel involved then the process could be much smoother. > 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.) - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 15 Jun 2007, Greg KH wrote: Usually you don't do that by doing a 'mv' otherwise you are almost guaranteed stale and mixed up content for some period of time, not to mention the issues surrounding paths that might be messed up. on the contrary, useing 'mv' is by far the cleanest way to do this. mv htdocs htdocs.old;mv htdocs.new htdocs this makes two atomic changes to the filesystem, but can generate thousands to millions of permission changes as a result. I agree, and yet, somehow, SELinux today handles this just fine, right? :) no it doesn't, SELinux as-is should take no action when the above command is run, but SELinux implementing path-based permissions will have to relabel every file or directory in both trees. Let's worry about speed issues later on when a working implementation is produced, I'm still looking for the logical reason a system like this can not work properly based on the expected AA interface to users. if you are willing to live with the race conditions from the slow (re)labeling and write the software to scan the entire system to figure out the right policies (and then use inotify to watch the entire system for changes and (re)label the appropriate files) and accept that you can't get any granular security for filesystems that don't nativly support it you could make SELinux behave like AA. but why should they be required to? are you saying that the LSM hooks are not a valid API and should be removed with all future security modules being based on SELinux? David Lang - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
