I had always understood that the essentail difference between ufsdump and
other archiving tools, such as tar, was that it dumped inodes rather than
dumping files.

And so I had assumed that if you 'mv'ed a file, all you were actually
doing was to change the directory (which is itself stored in an inode) and
that the inode containing the actual file data, together with its update
and last-used times and its ownership and access information, would remain
unchanged.

In which case I would expect the next incremantal dump to dump the inode
for the revised directory, but not that for the file.

But it seems it ain't so. I notice this particularly because I have in my
/var/log

-rw-r--r-- 1 root sys 1099260 Mar 8 12:50 syslog
-rw-r--r-- 1 root sys 2575991 Mar 5 02:39 syslog.0
-rw-r--r-- 1 root sys 2824650 Feb 26 02:22 syslog.1
-rw-r--r-- 1 root sys 2637420 Feb 19 02:34 syslog.2
-rw-r--r-- 1 root sys 2965750 Feb 12 02:31 syslog.3
-rw-r--r-- 1 root sys 3085544 Feb 5 02:42 syslog.4
-rw-r--r-- 1 root sys 2707276 Jan 29 02:23 syslog.5
-rw-r--r-- 1 root sys 2607284 Jan 21 17:38 syslog.6
-rw-r--r-- 1 root sys 2820895 Jan 14 17:39 syslog.7

(yes, I really don't need to keep that many, but that seems the default in
Solaris 10).

Of those, only syslog actively changes. The rest arise simply from 'mv'ing
them all up one during the weekly cleanup and throwing away the old
syslog.7. The inodes and their contents remain unchanged (as may be
verified by using ls -i).

Nevertheless, subsequent incremental dumps seem to redump the whole of
each file (and, as you will see, that amounts to about 24MB). Why should
that be so? And can it be avoided?

On further examination, I see that the ctime (which presumably is stored
in the inode) of these files gets altered when the 'mv' takes place:

root# ls -lct /var/log/syslog*
-rw-r--r-- 1 root sys 1099260 Mar 8 12:50 /var/log/syslog
-rw-r--r-- 1 root sys 2575991 Mar 5 03:10 /var/log/syslog.0
-rw-r--r-- 1 root sys 2824650 Mar 5 03:10 /var/log/syslog.1
-rw-r--r-- 1 root sys 2637420 Mar 5 03:10 /var/log/syslog.2
-rw-r--r-- 1 root sys 2965750 Mar 5 03:10 /var/log/syslog.3
-rw-r--r-- 1 root sys 3085544 Mar 5 03:10 /var/log/syslog.4
-rw-r--r-- 1 root sys 2707276 Mar 5 03:10 /var/log/syslog.5
-rw-r--r-- 1 root sys 2607284 Mar 5 03:10 /var/log/syslog.6
-rw-r--r-- 1 root sys 2820895 Mar 5 03:10 /var/log/syslog.7

which maybe explains why ufsdump decides to redump them, but why should a
'mv' (or rather the rename(2) which presumably underlies 'mv') change the
ctime? According to stat(2)

st_ctime Time when file status was last changed.
Changed by the following functions: chmod(),
chown(), creat(), link(2), mknod(), pipe(),
unlink(2), utime(), and write().

and 'rename' is conspicuously absent from that list.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Charles Lindsey wrote:

> ...
> which maybe explains why ufsdump decides to redump them, but why should a
> 'mv' (or rather the rename(2) which presumably underlies 'mv') change the
> ctime? According to stat(2)
>
> st_ctime Time when file status was last changed.
> Changed by the following functions: chmod(),
> chown(), creat(), link(2), mknod(), pipe(),
> unlink(2), utime(), and write().
>
> and 'rename' is conspicuously absent from that list.

A mv is performed by linking the inode to a new directory entry, and then
unlinking the inode from the old directory entry - as i was tought.
-job

In article <45F1FD2D.13061F6C@Chello.nl>, Job Eisses <jei@Chello.nl> wrote:
>Charles Lindsey wrote:
>
>> ...
>> which maybe explains why ufsdump decides to redump them, but why should a
>> 'mv' (or rather the rename(2) which presumably underlies 'mv') change the
>> ctime? According to stat(2)
>>
>> st_ctime Time when file status was last changed.
>> Changed by the following functions: chmod(),
>> chown(), creat(), link(2), mknod(), pipe(),
>> unlink(2), utime(), and write().
>>
>> and 'rename' is conspicuously absent from that list.
>
>A mv is performed by linking the inode to a new directory entry, and then
>unlinking the inode from the old directory entry - as i was tought.

mv uses the rename syscall. rename() is an "atomic" operation.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

In article <JELHCx.8BA@clerew.man.ac.uk>,
Charles Lindsey <chl@clerew.man.ac.uk> wrote:
>I had always understood that the essentail difference between ufsdump and
>other archiving tools, such as tar, was that it dumped inodes rather than
>dumping files.

ufsdump basically does nothing different than "star". The main difference is
that ufsdump is accessing the filesystem in an unclean way by directly reading
the raw disk device while star uses the "official method" to access files.

In former times (~ 1982), the unclean way of ufsdump was faster.

Today, machines have more RAM and better caching strategies in the OS, so the
method used by ufsdump is slower than star's methos as the tricks used in
ufsdump do not scale.

>And so I had assumed that if you 'mv'ed a file, all you were actually
>doing was to change the directory (which is itself stored in an inode) and
>that the inode containing the actual file data, together with its update
>and last-used times and its ownership and access information, would remain
>unchanged.

This is what POSIX requires, but it may be that older filesystems (like UFS)
behave different.

>In which case I would expect the next incremantal dump to dump the inode
>for the revised directory, but not that for the file.

If you have a POSIX compliant filesystem that does not in addition try
to be compatible with old UNIX versions, you are right.


>Nevertheless, subsequent incremental dumps seem to redump the whole of
>each file (and, as you will see, that amounts to about 24MB). Why should
>that be so? And can it be avoided?

>which maybe explains why ufsdump decides to redump them, but why should a
>'mv' (or rather the rename(2) which presumably underlies 'mv') change the
>ctime? According to stat(2)
>
> st_ctime Time when file status was last changed.
> Changed by the following functions: chmod(),
> chown(), creat(), link(2), mknod(), pipe(),
> unlink(2), utime(), and write().
>
>and 'rename' is conspicuously absent from that list.

Because rename (in theory) may not need to touch the inode.
A filesystem is POSIX compliant even if it does not update st_ctime.

BTW: star uses the same inode based incremental dump mechanism as ufsdump
does, so it behaves the same way as ufsdump (except for being faster and
for using a clean way to access files). If you find a filesystem that
does not update st_ctime with rename(2), you will be able to verify your
assumption on incremental dumps because star works in a filesystem independent
way.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

In <55fl78F24cf37U1@mid.dfncis.de> js@cs.tu-berlin.de (Joerg Schilling) writes:

>In article <JELHCx.8BA@clerew.man.ac.uk>,
>Charles Lindsey <chl@clerew.man.ac.uk> wrote:

>>And so I had assumed that if you 'mv'ed a file, all you were actually
>>doing was to change the directory (which is itself stored in an inode) and
>>that the inode containing the actual file data, together with its update
>>and last-used times and its ownership and access information, would remain
>>unchanged.

>This is what POSIX requires, but it may be that older filesystems (like UFS)
>behave different.

Well I am using UFS, because that seems to be the default under Solaris
10, and indeed it does not seem to offer you any other. What options other
than UFS have I actually got?

It is the st_ctime in the inode that is getting changed by the mv.
st_atime and st_mtime are unchanged until you actually read or edit the
file. But, of course, ufsdump, quite rightly, looks at st_ctime.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

In article <JEsuMp.FBu@clerew.man.ac.uk>,
Charles Lindsey <chl@clerew.man.ac.uk> wrote:
>In <55fl78F24cf37U1@mid.dfncis.de> js@cs.tu-berlin.de (Joerg Schilling) writes:
>
>>In article <JELHCx.8BA@clerew.man.ac.uk>,
>>Charles Lindsey <chl@clerew.man.ac.uk> wrote:
>
>>>And so I had assumed that if you 'mv'ed a file, all you were actually
>>>doing was to change the directory (which is itself stored in an inode) and
>>>that the inode containing the actual file data, together with its update
>>>and last-used times and its ownership and access information, would remain
>>>unchanged.
>
>>This is what POSIX requires, but it may be that older filesystems (like UFS)
>>behave different.
>
>Well I am using UFS, because that seems to be the default under Solaris
>10, and indeed it does not seem to offer you any other. What options other
>than UFS have I actually got?
>
>It is the st_ctime in the inode that is getting changed by the mv.
>st_atime and st_mtime are unchanged until you actually read or edit the
>file. But, of course, ufsdump, quite rightly, looks at st_ctime.

If ufsdump would behave otherwise, it would omit the files that you did
e.g. extract from a tar archive to an old mtime.....

If you like to experiment with this, you could use star in it's incremental mode
and use the option "-dumpmeta", but be very careful this is is not intended for
real backup use....

ftp://ftp.berlios.de/pub/star/alpha/

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily