On 2018年01月10日 23:33, Nikolay Borisov wrote: > > > On 10.01.2018 03:30, Qu Wenruo wrote: >> That system chunk can be relocated by balance, and in that case new >> chunk may start beyond 1M. >> >> So the most reliable method would be manually checking the the first >> device extent of this device, and to determine if we should minus that 1M. >> >> If the first device extent starts beyond 1M, reducing 1M would be good. >> Or don't modify it. > > So assuming I run generic/015 on a system with your mkfs patches to put > system chunk after 1mb and I implement a logic in > btrfs_calc_avail_data_space to subtract 1mb if the first extent of a > device starts at 1mb. In that case the test is still going to fail i.e > have the discrepancy of 1mb due to 1mb being subtracted first due to > there being unallocated space on the device, but then on the second df > btrfs_calc_avail_data_space will return 0 so df is going to report space > only from the block groups. > > > Thinking a bit more I think with your mkfs.btrfs patch there is no need > to check where the device extent starts, since now we are guaranteed to > always have a hole of at least 1mb at the beginning. The check here is mainly for old filesystems, whose device extent can start in the reserved range. But considering the difference will be no larger than 1MB, and using small filesystem (100ish MiB) is already very rare in btrfs, such difference won't really cause much problem, except for the test case. Thanks, Qu > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Attachment:
signature.asc
Description: OpenPGP digital signature
