<html><body><p><font size="2">> </font><font face="Helvetica">1) How is file deletion handled?</font><br><br><font face="Helvetica">This depends on whether there's snapshot and whether COW is needed. If COW is not needed or there's no snapshot at all, then the file deletion is handled as non-compressed file(don't decompress the data blocks and simply discard the data blocks, then delete the inode). </font><br><br><font face="Helvetica">However, even if COW is needed, then uncompression before COW is only needed when one of following conditions is true.</font><br><font face="Helvetica">1) the block to be moved is not the first block of a compression group(10 blocks is compression group since block 0).</font><br><font face="Helvetica">2) the compression group ends beyond the last block of destination file(file in latest snapshot).</font><br><font face="Helvetica">3) the compression group is not full and the destination file is larger.</font><br><font face="Helvetica">4) the compression group ends at the last block of destination file, but the size between source and destination files are different.</font><br><font face="Helvetica">5) the destination file already has some allocated blocks(COWed) within the compression group.</font><br><br><font face="Helvetica">> 2) Are there any guidelines</font><br><br><font face="Helvetica">LZ4 compression algorithm is already made good trade-off between performance and compression ratio. So it really depends on your data characters and access patterns. For example: if the data is write-once but read-many times, then there shouldn't be too much overhead as only compressed one time(I suppose decompression with lz4 doesn't consume too much resource as compression). If your data is really randomized, then compressing with lz4 doesn't give back too much help on storage space save, but still need to compress data as well as decompression when needed. But note that compressed data could also reduce the overhead to storage and network because smaller I/O size would be done for compressed file, so from application overall point of view, the overhead could be not added at all....</font><br><br><font size="2">Regards, The Spectrum Scale (GPFS) team<br><br></font><BR>
</body></html>