scuss-boun...@spectrumscale.org
; gpfsug main discussion list
; Leo Luan
Subject: Re: [gpfsug-discuss] Compression question
Caution - This email from zho...@cn.ibm.com originated outside Imperial
The statement from Olaf and Alex in below emails are correct. Firstly,
compressing and decompressing files in a
lt;daniel.kid...@uk.ibm.com>Sent: 28 November 2019 12:30To: gpfsug-discuss@spectrumscale.org <gpfsug-discuss@spectrumscale.org>Cc: gpfsug-discuss@spectrumscale.org <gpfsug-discuss@spectrumscale.org>Subject: Re: [gpfsug-discuss] Compression question Caution - This email from daniel.kid...@uk
gpfsug-discuss@spectrumscale.org
Cc: gpfsug-discuss@spectrumscale.org
Date: 28-11-2019 20:58
Subject:[EXTERNAL] Re: [gpfsug-discuss] Compression question
Sent by:gpfsug-discuss-boun...@spectrumscale.org
Olaf's explanation makes excellent sense.
So is this definitel
er 2019 12:30To: gpfsug-discuss@spectrumscale.org Cc: gpfsug-discuss@spectrumscale.org Subject: Re: [gpfsug-discuss] Compression question
Caution - This email from daniel.kid...@uk.ibm.com originated outside Imperial
Alexander, Can you then
on behalf of Daniel Kidger
Sent: 28 November 2019 12:30To: gpfsug-discuss@spectrumscale.org Cc: gpfsug-discuss@spectrumscale.org Subject: Re: [gpfsug-discuss] Compression question Caution
- This email from daniel.kid...@uk.ibm.com
originated outside Imperial Alexander, Can you then confirm th
der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
> HRB 243294
>
>
>
> - Original message -
> From: "Luis Bolinches"
> Sent by: gpfsug-discuss-boun...@spectrumscale.org
> To: "gpfsug main discussion list"
> Cc:
> Sub
discuss@spectrumscale.org Cc: gpfsug-discuss@spectrumscale.org Subject: Re: [gpfsug-discuss] Compression question
Caution - This email from daniel.kid...@uk.ibm.com originated outside Imperial
>
@imperialRCS @imperialRSE
From: gpfsug-discuss-boun...@spectrumscale.org
on behalf of Daniel Kidger
Sent: 28 November 2019 12:30
To: gpfsug-discuss@spectrumscale.org
Cc: gpfsug-discuss@spectrumscale.org
Subject: Re: [gpfsug-discuss] Compression question
on Campus London, SW7 2AZ
> T: 07712388129
> E: b.cre...@imperial.ac.uk
> W: www.imperial.ac.uk/ict/rcs
>
> @imperialRCS @imperialRSE
>
>
>
> From: gpfsug-discuss-boun...@spectrumscale.org
> on behalf of Daniel Kidger
>
> Sent: 28 November 2019 12:30
&g
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
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
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
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
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:
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
15 matches
Mail list logo
