On Fri January 6 2006 17:12, Herbert Poetzl wrote:
> On Fri, Jan 06, 2006 at 03:47:56PM -0600, Michael S. Zick wrote:
> > On Fri January 6 2006 14:19, Herbert Poetzl wrote:
> > >
> > > no, the different taggings work equally well, it's
> > > unfortunate that there is no xid aware backup and
> > > restore tool, otherwise the transition could be
> > > seamless ...
> > >
> > Herbert,
> > Seamless backup and restore of xid between different
> > xid marking systems leads me to a dumb question:
> >
> > Is there a flag or token indicating which tagging
> > system is in use? In the inode? In superblock?
>
> no
>
> > In kernel?
>
> yes, the kernel (on 2.x) knows about the tagging
> info and exports that information to userspace
> (the testfs.sh scripts reports that)
>
Meaning it is not practical.
Since the kernel (and what it exports) can be changed
independently of how the files are recorded.
You got three inode bits to use for indicators
of which xid system was used? (inode.xid.version?)
Yes, I think it has to be at the inode level.
Consider a ro bind mount...
Kernel-1; xid-method-1; root=/dev/hda
auxiliary mount: /dev/hdb
Kernel-2; xid-method-2; root=/dev/hdb
auxiliary mount: /dev/hda
Now bind mount the two trees together, I don't
see where anything other than an inode.xid.version
will do the job. Otherwise one of the file systems
will be read/restored incorrectly depending on which
kernel is running.
The above example is perhaps extreme, but the same
thing can happen over time...
Backup files.
Change Kernel.
Restore files.
Sequence would work.
Change Kernel.
Backup files.
Restore files.
Now the filesystem is trash.
Mike
> this is the relevant code (bash):
>
> INFO=(`sed 's/.*:\t//' /proc/virtual/info 2>/dev/null || echo '<none>'`)
> case ${INFO[2]:1:1} in
> 0) TAGI="none" ;;
> 1) TAGI="uid16" ;;
> 2) TAGI="gid16" ;;
> 3) TAGI="ugid24" ;;
> 4) TAGI="intern" ;;
> 5) TAGI="runtime" ;;
> *) TAGI="unknown" ;;
> esac
>
> best,
> Herbert
>
> > Just point me in the right direction to the appropriate
> > source code - I will see if I can figure something out.
> > Most likely a tag<->text conversion such as used for
> > ACLs.
> >
> > Mike
> > _______________________________________________
> > Vserver mailing list
> > Vserver@list.linux-vserver.org
> > http://list.linux-vserver.org/mailman/listinfo/vserver
>
>
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Fri Jan 6 23:40:37 2006