Right, we do expect userspace to use a fixed block size, but we give scopeMaybe it is enough to just take atomic_write_unit_min_bytes
in the API to use variable size.
only, and allow length to be N * atomic_write_unit_min_bytes.
But it may violate atomic write boundary?
Can you provide actual NVMe boundary value?The hardware should recognize unit size by start LBA, and check if length isPlease note that we also need to consider:
valid, so probably the interface might be relaxed to:
1) start lba is unit aligned, and this unit is in the supported unit
range(power_2 in [unit_min, unit_max])
2) length needs to be:
- N * this_unit_size
- <= atomic_write_max_bytes
- any atomic write boundary (from NVMe)
Firstly natural aligned write won't cross boundary, so boundary should
be >= write_unit_max,
see blow code from patch 10/21:
+static bool bio_straddles_atomic_write_boundary(loff_t bi_sector,
+ unsigned int bi_size,
+ unsigned int boundary)
+{
+ loff_t start = bi_sector << SECTOR_SHIFT;
+ loff_t end = start + bi_size;
+ loff_t start_mod = start % boundary;
+ loff_t end_mod = end % boundary;
+
+ if (end - start > boundary)
+ return true;
+ if ((start_mod > end_mod) && (start_mod && end_mod))
+ return true;
+
+ return false;
+}
+
Then if the WRITE size is <= boundary, the above function should return
false, right?
Looks like it is power_of(2) & aligned atomic_write_max_bytes?
- virt boundary (from NVMe)virt boundary is applied on bv_offset and bv_len, and NVMe's virt
bounary is (4k - 1), it shouldn't be one issue in reality.
And, as I mentioned elsewhere, I am still not 100% comfortable that we don'tmax_sectors_kb should be bigger than atomic_write_max_bytes actually,
pay attention to regular max_sectors_kb...
then what is your concern?