the problem should go away and the
extent gets trimmed to 76 blocks.
..if so, then, yes, it does. We end up with this:
0: [0..14079]: 42432..56511 0 (42432..56511) 14080
1: [14080..14687]: 177344..177951 0 (177344..177951) 608
2: [14688..14719]: 350720..350751 1 (171520..171551) 32
Good, that's how it should work. 🙂
I'll update the patchset I have with these fixes.
ok, thanks
Update:
So I have some more patches from trying to support both truncate and
fallocate + punch/insert/collapse for forcealign.
I seem to have at least 2x problems:
- unexpected -ENOSPC in some case
- sometimes misaligned extents from ordered combo of punch, truncate, write
I don't know if it is a good use of time for me to try to debug, as I
guess you could spot problems in the changes almost immediately.
Next steps:
I would like to send out a new series for XFS support for atomic writes
soon, which so far included forcealign support.
Please advise on your preference for what I should do, like wait for
your forcealign update and then combine into the XFS support for atomic
write series. Or just post the doubtful patches now, as above, and go
from there?
Thanks,
John
