Re: [gpfsug-discuss] Compression question

2019-11-28 Thread Cregan, Bob
Hi Thanks very much everyone for this. Bob Bob Cregan HPC Systems Analyst Information & Communication Technologies Imperial College London, South Kensington Campus London, SW7 2AZ T: 07712388129 E: b.cre...@imperial.ac.uk W: www.imperial.ac.uk/ict/rcs

Re: [gpfsug-discuss] Compression question

2019-11-28 Thread Hai Zhong HZ Zhou
The statement from Olaf and Alex in below emails are correct. Firstly, compressing and decompressing files in active file system doesn't not trigger data blocks copy-on-write, that is just deallocating the unnecessary original data blocks and put compressed data in few data blocks, and no data

Re: [gpfsug-discuss] Compression question

2019-11-28 Thread IBM Spectrum Scale
Hai Zhong, Can you please help the customer with their compression related query. Regards, The Spectrum Scale (GPFS) team -- If you feel that your question can benefit other users

Re: [gpfsug-discuss] python package installs fail due to attribute copy error (GPFS 5.0.2)

2019-11-28 Thread IBM Spectrum Scale
Hi Diane, Can you please help customer with the below issue. Or else can you point me to the right folks who can help here. Regards, The Spectrum Scale (GPFS) team -- If you feel

Re: [gpfsug-discuss] Compression question

2019-11-28 Thread Daniel Kidger
Olaf's explanation makes excellent sense.  So is this definitely the case? ..     The now snapshotted inode is not updated when a live file is compressed, as it point to the current inode which itself has compressed blocks (and the compressed flag set).    And likewise for deeper (older)

Re: [gpfsug-discuss] Compression question

2019-11-28 Thread Olaf Weiser
Hi Alex, not 100% sure about my answer.. but so far as I see it.. it is working, because of the so called "dito resolution " .. In the snaphost's inode .. die pointer to the DA's point the the next (more recent) inode information .. so accessing a file in a snapshot- "redirects" the request to

Re: [gpfsug-discuss] Compression question

2019-11-28 Thread Luis Bolinches
That is the fix. Before it was an error. So blocks that are pointed from active get compressed. Ones that are no longer linked are not modified. -- Cheers > On 28. Nov 2019, at 16.03, Alexander Wolf wrote: > >  > I see the same behavior of mmlsattr on my system (with some post 5.0.4 >

Re: [gpfsug-discuss] Compression question

2019-11-28 Thread Alexander Wolf
I see the same behavior of mmlsattr on my system (with some post 5.0.4 development build). Funny enough if I look at the file content in the snapshot it gets properly decompressed.   Mit freundlichen Grüßen / Kind regards

Re: [gpfsug-discuss] Compression question

2019-11-28 Thread Cregan, Bob
Hi 5.0.2 with a hotfix for a lz4 compression bug Bob Bob Cregan HPC Systems Analyst Information & Communication Technologies Imperial College London, South Kensington Campus London, SW7 2AZ T: 07712388129 E: b.cre...@imperial.ac.uk W:

Re: [gpfsug-discuss] Compression question

2019-11-28 Thread Luis Bolinches
Which version are you running? I was involved on a big for compressed file sets and snapshots that were related to what you see. -- Cheers > On 28. Nov 2019, at 14.57, Cregan, Bob wrote: > >  > Hi > Sounds logical - except the snap metadata does not have the compression > flag set.

Re: [gpfsug-discuss] Compression question

2019-11-28 Thread Alexander Wolf
Actually I am not aware of an easy way to do this. But to back my statement: I had created a file of 1G. Made a snapshot "snap1". Wrote new data over the whole file. Created "snap2". Compressed file. This is what stat says:   [root@alex-11 ~]# stat /mnt/gpfs0/testfile   File: /mnt/gpfs0/testfile 

Re: [gpfsug-discuss] Compression question

2019-11-28 Thread Daniel Kidger
Alexander,   Can you then confirm then that the inodes in the snapshot will now point to fewer but compressed blocks ? Daniel   _Daniel Kidger IBM Technical Sales Specialist Spectrum Scale, Spectrum NAS and IBM Cloud Object Store+44-(0)7818

Re: [gpfsug-discuss] Compression question

2019-11-28 Thread Alexander Wolf
I just tested this. Compressing a file did free up space in the file system. Looks like our compression code does not trigger COW on the snapshot. You can test this yourself by looking into mmlssnapshot -d (please not on a large production fs, this command is expensive).   Mit freundlichen Grüßen

Re: [gpfsug-discuss] Compression question

2019-11-28 Thread Luis Bolinches
Hi   Same principle COW. The data blocks do not get modified. --Ystävällisin terveisin / Kind regards / Saludos cordiales / Salutations / SalutacionsLuis Bolinches Consultant IT SpecialistMobile Phone: +358503112585https://www.youracclaim.com/user/luis-bolinches"If you always give you will always

Re: [gpfsug-discuss] Compression question

2019-11-28 Thread Cregan, Bob
Just to clarify this is SS compression, so mmchattr --compression yes or an ILM equivalent So not a regular modification. Bob Bob Cregan HPC Systems Analyst Information & Communication Technologies Imperial College London, South Kensington Campus London, SW7 2AZ T: 07712388129 E:

Re: [gpfsug-discuss] Compression question

2019-11-28 Thread Luis Bolinches
Hi   snaps are copy on write (COW). No blocks are written to snap compressed or not compressed situation   ### Create a file Take snap Modify file, only the blocks that are modified are linked from the active i-nodes, snap i-nodes point to the original blocks. you only free space when a data block

[gpfsug-discuss] Compression question

2019-11-28 Thread Cregan, Bob
Hi All, Can someone answer the following question on compression in a snapshot context? We have tried various experiments and they are inconclusive - too tedious to go into the detail. What happens to the snapshot when a file is compressed in SS? The logic as I see it is ### In