[gpfsug-discuss] mmbackup issue

[Grunenberg, Renar]

Hallo Valdis,
first thanks for the explanation we understand that, but this problem generate only 2 Version at tsm server for the same file, in the same directory. This mean that mmbackup and the .shadow... has no possibility to have for the same file in the same directory more then 2 backup versions with tsm. The native ba-client manage this. (Here are there already different inode numbers existent.) But at TSM-Server side the file that are selected at 'ba incr' are merged to the right filespace and will be binded to the mcclass >2 Version exist.




Renar Grunenberg
Abteilung Informatik – Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon:  09561 96-44110
Telefax:  09561 96-44104
E-Mail:   Renar.Grunenberg at huk-coburg.de
Internet: www.huk.de
=======================================================================
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas.
=======================================================================
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.
=======================================================================

-----Ursprüngliche Nachricht-----
Von: gpfsug-discuss-bounces at spectrumscale.org [mailto:gpfsug-discuss-bounces at spectrumscale.org] Im Auftrag von valdis.kletnieks at vt.edu
Gesendet: Mittwoch, 20. Juni 2018 16:45
An: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Betreff: Re: [gpfsug-discuss] mmbackup issue

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....