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: [email protected] 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: [email protected] [mailto:[email protected]] Im Auftrag von [email protected] Gesendet: Mittwoch, 20. Juni 2018 16:45 An: gpfsug main discussion list <[email protected]> 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.... _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
