Hi,
> It is probably very common now to use usb drives (both flash
> and real) and swap among systems. I'd expect synthetic inode
> numbers to change if the contents are modified between mounts.
Another risk could be changing device numbers due
to automagical hardware detection.
I'm waiting for the first bug reports to come in.
> If I arbitrarily mount different
> volumes on top of an existing directory between fulls
> and incrementals, what should an incremental tar contain?
A lot of "changed" files. Righteously.
My concern is more about situations which appear stable
to the user. Like mounting a filesystem and finding
all inode numbers hashed to new values.
> > That is because inodes form a directed graph but the
> > user model of data storage is a tree. Hardlinks are
> > handy but introduce severe fundamental problems.
>
> You don't want hardlinks of directories, but hardlinks
> of files are fundmental to unix filesystem semantics.
They are about the type which is hardest to explain
to a novice. First one preaches about trees and access
paths and then one shares leafs between branches.
Nevertheless, i agree : some system parts and applications
rely on hardlinks. Therefore one has to maintain them with
the most general backup method.
> > "For situations where hardlinks do matter, backup methods
> Rephrase that to 'where unix files matter'. All unix files
> exist as hard links.
Only a small fraction of users is aware of that.
The others never encounter situations where this matters.
> Archival storage formats like tar/cpio/dump exist for a reason.
> ISO-9660 doesn't represent unix owner/group/permissions/setuid/setgid
> either. Omit them on a restore and your box won't work.
If it's plain user data, then those attributes are easily
restored. After all, a non-superuser cannot create files
under a different user-id that her/his own.
If it's multiple user's data, then Rockridge extensions may help.
Alternatively a setfacl list works wonders.
Of course, i would not advise to store anything else than
plain data in ISO-9660.
But hey, the problem of dull backups is solved with ISO-9660.
Whenever i get a paranoid nightmare i may mount a backup volume
and look into my files by help of the appropriate application.
> Any system that expects to restore a working unix box
> should deal with hard links.
Therefore i have to test with afio and star.
(Although i would be very astonished if a star level=0
backup would not restore all hard links as they were.)
> > So GNU-tar not only ignores the existence of inode-problematic
> > filesystems
>
> No, it relies on the semantics of stat().
The man page of stat says nothing about persistence of
inode numbers. It is said that somewhere in POSIX there
is some mentioning of inodes. Any hint is welcome.
> > but also the existence of SuSE 9.0 ReiserFS ???
> > (It is the _default_ filesystem of the toadies.)
>
> If the filesystem says a file changed, it is taken in an incremental.
> If your filesystem doesn't reliably note changes, then you should
> not trust incrementals.
I estimate that there are more Linux filesystem instances
with non-changing ctime than there have ever been other Unix
filesystem instances.
May others leave them behind - i provide incremental backup for them.
> I've never seen ctime described as anything but inode change
> time. What man page says otherwise?
We do not agree about wether link()/unlink() is the
mandatory method to rename a file. I see it as a deliberate
implementation decision and rather as an accident if an
intermediate change of the inode's link count updates ctime.
> Place the blame where it belongs. The original design and
> specification was solid.
It left the question open and two groups of squatters
occupied the empty space.
If renaming affects the inode, then it affects ctime.
If renaming only affects the directory, then ctime has
to stay unchanged.
That's what the man pages imply. As clear as "int" semantics
in C. (Probably same fathers and same late night booze.)
Whatever, the problem is out there. I am a victim myself
and i refuse to do daily full backups of 100 GB.
> > Thanks for the hint with the hardlinks. I confess not to
> > have ever thought about refiddling those at restore time.
>
> I'd like to find something that handled them efficiently.
> I'd imagine
> your backup technique would take days for even the first copy
> if it reads each instance of the links separately to save a
> checksum entry for it.
With checksums, recording the level 0 tree state of 900 GB
would last about 15 hours on my box. The incremental backup
time would depend much on the directory timestamps. If they
are all young and all their files have old timestamps then
again 15 hours would be needed. (Expect rather 5 hours
after a week of activity.)
With inode numbers it depends more on the number of files
and wether the system has a bad hair minute or not.
My ugliest test tree of 3.8 million files is traversed
in about 20 minutes despite some really pathological
directories.
The hardlink detection and restoring problem looks quite
expensive in terms of computing time and memory. At least
if there are lots of such shared inodes.
Have a nice day :)
Thomas
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.