[gpfsug-discuss] mmbackup issue

[valdis.kletnieks at vt.edu]

On Wed, 20 Jun 2018 14:08:09 -0000, "Grunenberg, Renar" said:

> There are after each test (change of the content) the file became every time 
> a new inode number. This behavior is the reason why the shadowfile think(or the
> policyengine) the old file is never existent

That's because as far as the system is concerned, this is a new file that happens
to have the same name.

> At SAS the data file will updated with a xx.data.new file and after the close
> the xx.data.new will be renamed to the original name xx.data again. And the
> miss interpretation of different inodes happen again.

Note that all the interesting information about a file is contained in the
inode (the size, the owner/group, the permissions, creation time, disk blocks
allocated, and so on).  The *name* of the file is pretty much the only thing
about a file that isn't in the inode - and that's because it's not a unique
value for the file (there can be more than one link to a file).  The name(s) of
the file are stored in the parent directory as inode/name pairs.

So here's what happens.

You have the original file xx.data.  It has an inode number 9934 or whatever.
In the parent directory, there's an entry "name xx.data -> inode 9934".

SAS creates a new file xx.data.new with inode number 83425 or whatever.
Different file - the creation time, blocks allocated on disk, etc are all
different than the file described by inode 9934. The directory now has
"name xx.data -> 9934" "name xx.data.new -> inode 83425".

SAS then renames xx.data.new - and rename is defined as "change the name entry
for this inode, removing any old mappings for the same name" .  So...

0) 'rename xx.data.new xx.data'. 
1) Find 'xx.data.new' in this directory. "xx.data.new -> 83425" . So we're working with that inode.
2) Check for occurrences of the new name. Aha.  There's 'xxx.data -> 9934'.  Remove it.
(2a) This may or may not actually make the file go away, as there may be other links and/or
open file references to it.)
3) The directory now only has '83425 xx.data.new -> 83425'.
4) We now change the name. The directory now has 'xx.data -> 83425'.

And your backup program quite rightly concludes that this is a new file by a name that
was previously used - because it *is* a new file.  Created at a different time, different blocks
on disk, and so on.

The only time that writing a "new" file keeps the same inode number is if the program
actually opens the old file for writing and overwrites the old contents.  However, this
isn't actually done by many programs (including vi and SAS, as you've noticed) because
if writing out the file encounters an error, you now have lost the contents - the old version
has been overwritten, and the new version isn't complete and correct.  So many programs
write to a truly new file and then rename, because if writing the new file fails, the old
version is still available on disk....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20180620/f5bc8b4f/attachment-0002.sig>