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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[adding cc: linux-xfs]

On Sun, Nov 5, 2017 at 10:17 AM, L A Walsh <lkml@xxxxxxxxx> wrote:
> Amir Goldstein wrote:
>>
>>
>>
>>>
>>> I then created a new xfs file system and mounted it on '/edge';
>>>
>>>    Ishtar:/edge> xfs_info .
>>>    meta-data=/dev/Data/Edge     isize=256    agcount=32,
>>>    agsize=16777200 blks     =                   sectsz=4096  attr=2
>>>    data     =                   bsize=4096   blocks=536870400, imaxpct=5
>>>             =                   sunit=16     swidth=64 blks
>>>    naming   =version 2          bsize=4096   ascii-ci=0
>>>    log      =internal           bsize=4096   blocks=262143, version=2
>>>             =                   sectsz=4096  sunit=1 blks, lazy-count=1
>>>    realtime =none               extsz=4096   blocks=0, rtextents=0
>>>
>>>
>>
>>
>> Your problem is that you do not have "ftype" feature in directory
>> name format, like this:
>>
>> naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
>>
>> Perhaps you have an old version of mkfs.xfs, not sure when
>> ftype=1 became the default format, but you can try to
>>   mkfs.xfs -n ftype=1
>>
>
> ----  Ah... no .. last I was told, if you turned on ftype=1,
> you had to also pull in crc'ing of all the meta-info.
> That has problems -- causes errors where there would be no
> problem, and was never tested on mature file systems that were
> already fragmented.
>
>
> Do you know if it was separated from crc32 -- for some inexplicable reason,
> if you wanted ftype, then the crc option would be forced on for you.
>

I don't know if there was a specific reason, but that's the way it is.

> I didn't want it as I didn't want it to flag errors in metadata that
> wasn't crucial and didn't want the speed slowdown.  Sigh.
>
> The problem on crc'ing the meta data, is that there is ALOT more meta
> data where detecting it will do more harm than good (like what nanosecond
> the file was last changed, for example).  I first ran into it
> taking the disk offline when I changed the guid on a newly formatted disk.
> That was fixed, but that was a warning shot...   How annoying.
>

I have never heard about those issues that you raise.
It sounds like a myth about XFS metadata CRC that should be debunked
so forwarding your message on to XFS list.
See also https://www.spinics.net/lists/xfs/msg19079.html

>
> From what you say, though only the upper layer needs to have the ftype=1.
> That's a new filesystem, so shouldn't make that much difference, but the
> lower fs's I'd want to use overlays with are older file systems.  But
> it sounds like those can remain as they are?
>
> (assuming they don't become upper layers in some multi-layer
> scenario)...
>

That is correct.

Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux