(Joi and David, please just read on)
Alexandre Oliva wrote:
>
> On Dec 4, 2000, Chris Karakas <[EMAIL PROTECTED]> wrote:
>
> > when you use SAMBA for the vfat partitions of your dual boot system,
> > it does not work.
>
> What do you mean? It works for me. Or are you talking about backing
> up vfat partitions while running GNU/Linux, in which case Samba isn't
> used at all; all you need is GNU tar?
>
I mean, I have tried both, without success. Here's what I tried:
Common part in both situations: The vfat partitions are mounted under
/dos as /dos/c, /dos/d etc. This is done in boot time from fstab:
/dev/hda3 /dos/c vfat
defaults,uid=500,gid=101,umask=002 0 0
/dev/hda5 /dos/d vfat
defaults,uid=500,gid=101,umask=002 0 0
etc.
uid is user chris, gid is group windows. AMANDA is member of the group.
This way *all* files get the permissions -rwxrwxr-x, i.e. they become
executables, even if they are not (probably due to the umask I use).
(That's the first thing that annoys me in mount: I can't map the archive
bit to the fictitious executable bits, as SAMBA is able to do when the
files are on ext2 partitions).
Now, for the two cases I have tested:
1. The Linux/AMANDA server becomes a SAMBA server too. The /dos/c,
/dos/d directories are exported as C and D respectively. In disklist I
would have //bacchus/c and //bacchus/d as the directories to be backed
up with tar, where bacchus is the Linux/AMANDA/SAMBA server.
2. No SAMBA in this case. I just tell AMANDA to use tar to backup the
directories /dos/c, /dos/d etc.
In both cases, incrementals are almost as large as full backups. It was
not always so: I had to boot Windows a few times (which I do not do very
often) to get this behaviour, so it is seems to be the problem of inodes
on vfat not being constant between mounts (after some kernel, I think
2.2.5). But, this is also curious: Even if I do not boot between two
successive AMANDA runs (i.e. the vfat filesystems stay mounted with the
same inode numbers), even then, a level 1 incremental which is done the
day after a level 0 was done, is almost as big as level 0. I can't
figure what's going on. From now on, I have set "dumpcycle 0" for the
vfat filesystems.
> Which has just given me yet another idea for you to try: set up your
> GNU/Linux box as a Samba server, and run your backups pretending the
> GNU/Linux box is actually running MS-Windows, i.e., arrange for it to
> be backed up through Samba. This will use Samba's mechanism of
> creating incrementals, which are quite different from those of GNU
> tar, and might get you around the problems you're facing with vfat,
> GNU tar, the Linux kernel or whatever :-)
>
This is exactly my case 1. Joi Ellis may remember that I contacted him
offline for this problem 6 months ago. I came to the coclusion that I
could not map the archive bit on some (even fictitious) execute bit,
which would then be used by SAMBA as an archive bit to compute
incrementals and that this was the reason incrementals were so big. So
the problem seems to be the vfat driver in mount, which cannot map the
archive bit at anything meaningful, although it sets it correctly,
according to David Woodhouse <[EMAIL PROTECTED]> in the
linux-kernel mailing list:
---snip
We do, however, correctly set the archive bit whenever we modify or
create
a file on a FAT filesystem, so it should be usable for its intended
purpose.
You just need to make sure your backup program uses the ATTR_ARCH flags
to
decide whether to back up each file, and resets the flag after/before
doing the backup.
---snip
Any more ideas now? How can this "ATTR_ARCH" flag be reasonably used
here?
--
Regards
Chris Karakas
Don´t waste your cpu time - crack rc5: http://www.distributed.net
