Re: [PATCH V6 2/2] common/populate: Ensure that S_IFDIR.FMT_BTREE is in btree format

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

 



on  2023/01/03 17:29, Ziyang Zhang wrote
> On 2023/1/3 14:54, xuyang2018.jy@xxxxxxxxxxx wrote:
>>
>>
>> on 2022/12/12 13:56, Ziyang Zhang wrote:
>>
>>> Sometimes "$((128 * dblksz / 40))" dirents cannot make sure that
>>> S_IFDIR.FMT_BTREE could become btree format for its DATA fork.
>>>
>>> Actually we just observed it can fail after apply our inode
>>> extent-to-btree workaround. The root cause is that the kernel may be
>>> too good at allocating consecutive blocks so that the data fork is
>>> still in extents format.
>>>
>>> Therefore instead of using a fixed number, let's make sure the number
>>> of extents is large enough than (inode size - inode core size) /
>>> sizeof(xfs_bmbt_rec_t).
>>
>> After this patch, xfs/083 and xfs/155 failed on my envrionment(6.1.0+
>> kernel).
>>
>> the 083 fail as below:
>> 1 fuzzing xfs with FUZZ_ARGS=-3 -n 32 and FSCK_PASSES=10
>>     2 + create scratch fs
>>     3 meta-data=/dev/sdb9              isize=512    agcount=4,
>> agsize=529878 blks
>>     4          =                       sectsz=512   attr=2, projid32bit=1
>>     5          =                       crc=1        finobt=1, sparse=1,
>> rmapbt=0
>>     6          =                       reflink=0    bigtime=1
>> inobtcount=1 nrext64=0
>>     7 data     =                       bsize=4096   blocks=2119510,
>> imaxpct=25
>>     8          =                       sunit=0      swidth=0 blks
>>     9 naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
>>    10 log      =internal log           bsize=4096   blocks=16384, version=2
>>    11          =                       sectsz=512   sunit=0 blks,
>> lazy-count=1
>>    12 realtime =none                   extsz=4096   blocks=0, rtextents=0
>>    13 + populate fs image
>>    14 MOUNT_OPTIONS =  -o usrquota,grpquota,prjquota
>>    15 + fill root ino chunk
>>    16 + extents file
>>    17 wrote 4096/4096 bytes at offset 0
>>    18 4 KiB, 1 ops; 0.0187 sec (212.891 KiB/sec and 53.2226 ops/sec)
>>    19 + btree extents file
>>    20 wrote 2097152/2097152 bytes at offset 0
>>    21 2 MiB, 2 ops; 0.0637 sec (31.370 MiB/sec and 31.3701 ops/sec)
>>    22 + inline dir
>>    23 + block dir
>>    24 + leaf dir
>>    25 + leafn dir
>>    26 + node dir
>>    27 + btree dir
>>    28 + inline symlink
>>    29 + extents symlink
>>    30 + special
>>    31 + local attr
>>    32 + leaf attr
>>    33 + node attr
>>    34 + btree attr
>>    35 + attr extents with a remote less-than-a-block value
>>    36 + attr extents with a remote one-block value
>>    37 + empty file
>>    38 + freesp btree
>>    39 wrote 4194304/4194304 bytes at offset 0
>>    40 4 MiB, 4 ops; 0.0941 sec (42.470 MiB/sec and 42.4696 ops/sec)
>>    41 + inobt btree
>>    42 + real files
>>    43 FILL FS
>>    44 src_sz 2052 fs_sz 8342940 nr 203
>>    45 failed to create ino 8578 dformat expected btree saw extents
>>    46 failed to create ino 8578 dformat expected btree saw extents
>>    47 (see /var/lib/xfstests/results//xfs/083.full for details)
>>
>>
>> It seems this logic can't ensure to creat a btree format dir and it
>> is a  extent format dir. Or I miss something?
>>
>>
>> Best Regards
>> Yang Xu
> 
> Hi Yang,
> 
> Looks like xfs/083 does call __populate_xfs_create_btree_dir.

Yes.
> Could you please share your test environment and config in
> detail and I will try to reproduce your report.

Of course, I use fedora31 and 6.1 kernel. xfsprogs uses upstream version 
xfsprogs: Release v6.0.0.

local.config
export TEST_DEV=/dev/sdb8
export TEST_DIR=/mnt/xfstests/test
export SCRATCH_DEV=/dev/sdb9
export SCRATCH_MNT=/mnt/xfstests/scratch
export XFS_MKFS_OPTIONS="-b size=4096 -m reflink=1"


disk info:
/dev/sdb8       566241280 608184319  41943040    20G 83 Linux
/dev/sdb9       608186368 625142447  16956080   8.1G 83 Linux


BTW, xfs/273 xfs/495 that called _scratch_populate_cached also failed 
with this commit under selinux Permissive status and passed under 
selinux  enforcing status. I guess the extend attr fork was filled
in selinux enabled status, so we can create btree dir by smaller number 
files.

Best Regards
Yang Xu
> 
> Regards,
> Zhang
> 




[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