linux-kernel - Re: Versioning file system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Jun 2007 10:05:15 +0200
From:	"Ph. Marek" <philipp.marek@...v.gv.at>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Chris Snook <csnook@...hat.com>,
	Jack Stone <jack@...keye.stone.uk.eu.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	akpm@...ux-foundation.org, viro@...iv.linux.org.uk,
	alan <alan@...eserver.org>
Subject: Re: Versioning file system

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 behaviour is important
>
> 3. An atomic snapshot is more useful than a bunch of disconnected
> per-file version.  Kind of like CVS vs SVN.

I believe that since some decision must be made *when* a snapshot is taken, 
and that should (has to) be done by userspace, a userspace versioning system 
for doing the backups is the right solution. [1]

Whether there is some filesystem (FUSE or native) that allows online browsing 
of the backups or not is another matter.

Ad 1: What userspace needs is
- atomic snapshots of complete directory trees, independent of mount
  boundaries (across filesystems)
- an atomic way to change the state of the filesystem for the *whole* system.
  For FSVS I'll try to use unionfs for that - populate some new directory with
  my tree of changes, then overmount that over "/", and move the files over
  one-by-one until the new directory is empty. (Must be checked on reboot, of
  course).

These are actually two similar operations (from the atomic view), but have to 
be done in completely different ways ... Maybe there could be some "better" 
interface (if there is one - I don't know what could really be removed from 
the above workflow).


Regards,

Phil
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/