Ocfs2 users - Aug 2019 - where can i find shared-du and shared-filefrag ?

----- Am 14. Aug 2019 um 22:44 schrieb herbert van den bergh
herbert.van.den.bergh at oracle.com:
> Hi Bernd,
> 
> The filefrag utility has been modified to report the shared flag of
> extents in the -e output[1], but it depends on the distro you use
> whether that version is available.
> 
> I don't think the shared-du changes were accepted upstream. You may be
> able to find the patches that implemented the feature in the du utility
> online somewhere.? If you're using Oracle Linux, I may be able to find
a
> version that works for you. Just let me know the OL and kernel version
> you're using.
Hi Herbert,

it does:

ll
total 31457284
-rw-r--r-- 1 qemu qemu 16106127360 Aug 15 14:26 greensql.raw
-rw-r--r-- 1 root root 16106127360 Aug 14 17:27 greensql.raw.snap

ha-idg-1:/mnt/ocfs2 # filefrag -e greensql.raw
Filesystem type is: 7461636f
File size of greensql.raw is 16106127360 (3932160 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..     255:   24772864..  24773119:    256:             shared
   1:      256..     511:   33108224..  33108479:    256:   24773120:
   2:      512..    1023:   33133312..  33133823:    512:   33108480:
   3:     1024..  262143:   24773888..  25035007: 261120:   33133824: shared
   4:   262144..  262399:   33030656..  33030911:    256:   25035008:
   5:   262400..  262655:   25035264..  25035519:    256:   33030912: shared
   6:   262656..  263167:   33030912..  33031423:    512:   25035520:
   7:   263168..  263423:   33059584..  33059839:    256:   33031424:
   8:   263424..  263935:   25036288..  25036799:    512:   33059840: shared
   9:   263936..  264191:   33060096..  33060351:    256:   25036800:
  10:   264192..  264703:   33031424..  33031935:    512:   33060352:
  11:   264704..  275455:   25037568..  25048319:  10752:   33031936: shared

I'm using SLES 12 SP4.

Some more questions:
The reflink (greensql.raw.snap) does not change, that means it's like a
snapshot ?
But if i delete the reflinked file (greensql.raw) my snapshot is lost because it
shares extents ?
If i delete the reflink, nothing happens beside that my snapshot is gone ?
That means i can delete it easily if i don't need it any longer ?
And if i need the current file i just use the reflinked file, i don't have
to do s.th like merging oder blockcommitting ?

Thanks.

Bernd


Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.helmholtz-2Dmuenchen.de&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=wXmkJNAUtutY0U9inuQWCbzSSRji5zLpyR0a_Mek4jM&m=6sshRY8B1mtyMi9SWF0Wm9GPhAzqMj_29yQzRC-98C0&s=NCyiimZepuZjTA9BqY5b5wexWxjIAaBvjxVviWz6EtE&e=
Aufsichtsratsvorsitzende: MinDir'in Prof. Dr. Veronika von Messling
Geschaeftsfuehrung: Prof. Dr. med. Dr. h.c. Matthias Tschoep, Heinrich Bassler,
Kerstin Guenther
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

On 8/15/19 5:36 AM, Lentes, Bernd wrote:
> ----- Am 14. Aug 2019 um 22:44 schrieb herbert van den bergh
herbert.van.den.bergh at oracle.com:
>
>> Hi Bernd,
>>
>> The filefrag utility has been modified to report the shared flag of
>> extents in the -e output[1], but it depends on the distro you use
>> whether that version is available.
>>
>> I don't think the shared-du changes were accepted upstream. You may
be
>> able to find the patches that implemented the feature in the du utility
>> online somewhere.? If you're using Oracle Linux, I may be able to
find a
>> version that works for you. Just let me know the OL and kernel version
>> you're using.
> Hi Herbert,
>
> it does:
>
> ll
> total 31457284
> -rw-r--r-- 1 qemu qemu 16106127360 Aug 15 14:26 greensql.raw
> -rw-r--r-- 1 root root 16106127360 Aug 14 17:27 greensql.raw.snap
>
> ha-idg-1:/mnt/ocfs2 # filefrag -e greensql.raw
> Filesystem type is: 7461636f
> File size of greensql.raw is 16106127360 (3932160 blocks of 4096 bytes)
>   ext:     logical_offset:        physical_offset: length:   expected:
flags:
>     0:        0..     255:   24772864..  24773119:    256:            
shared
>     1:      256..     511:   33108224..  33108479:    256:   24773120:
>     2:      512..    1023:   33133312..  33133823:    512:   33108480:
>     3:     1024..  262143:   24773888..  25035007: 261120:   33133824:
shared
>     4:   262144..  262399:   33030656..  33030911:    256:   25035008:
>     5:   262400..  262655:   25035264..  25035519:    256:   33030912:
shared
>     6:   262656..  263167:   33030912..  33031423:    512:   25035520:
>     7:   263168..  263423:   33059584..  33059839:    256:   33031424:
>     8:   263424..  263935:   25036288..  25036799:    512:   33059840:
shared
>     9:   263936..  264191:   33060096..  33060351:    256:   25036800:
>    10:   264192..  264703:   33031424..  33031935:    512:   33060352:
>    11:   264704..  275455:   25037568..  25048319:  10752:   33031936:
shared
Bernd,

It might be helpful to understand the way reflinks work if you compare 
the extents of both the original and the reflink. You'll see that the 
extents with the shared flag set use the same physical offsets (blocks 
on disk), but the extents that don't have the shared flag set have 
different physical offsets.
>
> I'm using SLES 12 SP4.
>
> Some more questions:
> The reflink (greensql.raw.snap) does not change, that means it's like a
snapshot ?
That's correct. Any change to an extent shared by the original file and 
the reflink will cause a copy to be made of the extent. The file which 
was changed will get the new modified extent, the other file keeps the 
original extent.
> But if i delete the reflinked file (greensql.raw) my snapshot is lost
because it shares extents ?
No, the reflink still contains all extents, both the ones that used to 
be shared and the ones that are unique to the reflinked
file.
> If i delete the reflink, nothing happens beside that my snapshot is gone ?
Correct, except that extents that were modified since the reflink was 
created which are no longer shared will be freed.
> That means i can delete it easily if i don't need it any longer ?
Yes.
> And if i need the current file i just use the reflinked file, i don't
have to do s.th like merging oder blockcommitting ?
I'm not sure what you're asking. If an application continues to 
read/write the original file, then it will be the "current" file, it
has
the most up to date data. The reflink will have the data as of the time 
it was created. So if you need the "old" version of the file from the 
time the snapshot was created, you use the reflink. If you need the 
"new" version of the file, you use the original. Think of the reflink
as
a backup which is still sharing extents that haven't been modified yet 
with the original.

Thanks,
Herbert.
>
> Thanks.
>
> Bernd
>   
>
> Helmholtz Zentrum Muenchen
> Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
> Ingolstaedter Landstr. 1
> 85764 Neuherberg
> www.helmholtz-muenchen.de
> Aufsichtsratsvorsitzende: MinDir'in Prof. Dr. Veronika von Messling
> Geschaeftsfuehrung: Prof. Dr. med. Dr. h.c. Matthias Tschoep, Heinrich
Bassler, Kerstin Guenther
> Registergericht: Amtsgericht Muenchen HRB 6466
> USt-IdNr: DE 129521671
>