Re: Bug? or normal behavior? if bug, then where? overlay, vfs, xfs, or ????

[L A Walsh <lkml@tlinx.org>]

Dave Chinner wrote:
>
>
> Changing the UUID on v5 filesystems is now implemented and
> supported:
>   
---
    And it won't have a problem if seen by a previous gen
tool -- like xfsrestore on an older "emergency boot disk"?

    If not, then I misunderstood what you wrote earlier.
>>    My issue was the inability to bench or use them separately.
>>     
>
> <sigh>
>
> Not an XFS problem:
>
> $ mkfs.xfs -f -m finobt=0 /dev/pmem0
> ....
>          =                       crc=1        finobt=0, sparse=0, rmapbt=0, reflink=0
> .....
>
> Yup, crc's enabled, finobt is not. As documented in the mkfs.xfs manpage.
>   

So you are saying I can set finobt to 0 or 1 with crc=0?

Because testing sigh crc=1 and finobt=0|1 isn't
the same as testing crc=0 and finobt=0|1.

I'm more interested in testing finobt's affect by itself and have
a secondary interest in the effect of the crc option because I would
like to use the finobt option (thus desire to test it first), but
do not currently want to use the crc otpion, thus it being of secondary
interest.

Again, if I can test finobt 0 or 1 with no requirements I turn on
crc, then I was mistaken in my earlier understanding.

So I still have 2 issues: UUID labels that don't preclude using older
emergency boot disks, to restore a file system, and the ability to
test finobt apart from other features.




> ge.
>
> IOWs, We can directly measure the impact of the finobt on
> workloads/benchamrks. And if we want to compare the impact of CRCs,
> then 'mkfs.xfs -f -isize=512, -m crc=0 <dev>' will be directly
> comparable to the above non-finobt filesystem. THis is how we
> benchmarked the changes in the first place....
>   
----
  

    That methodology is flawed.

    If the crc option is on during finobt being tested as 0 or 1,
the crc option on means different disk caching -- if the crc
option pulls in some or all of the finobt info, then you can't measure
the finobt option with the crc option turned on. Even if you turn the crc
feature off, if the disk has crc features, those also change how
information is read in.

    Only if you create a disk with no crc info on it, and then can test
finobt=0|1, can you see the relative performance of the finobt cases. 

    If it is the case that finobt can be toggled on a disk with no
crc data or option in use, then I've misunderstood previously read
constraints (or they've changed).

-l