On Wed, Jan 16, 2019 at 8:21 AM Jean-Pierre André
<jean-pierre.an...@wanadoo.fr> wrote:
>
> Thanks for your thorough tests and investigation.
You're welcome, Thanks for the patch!
> james harvey wrote:
> > On Wed, Jan 9, 2019 at 11:29 AM Jean-Pierre André
> > <jean-pierre.an...@wanadoo.fr> wrote:
> >> ntfs-3g does not reliably know where the ntfs partition
> >> sits on the device (there is a field in the boot sector for
> >> that, but it is not always fed in by formaters). The
> >> proposed patch assumes that the partition starts at
> >> a multiple of the granularity. Maybe this is where the
> >> discard_alignment comes into play, and maybe this
> >> should be taken into account when rounding the trim
> >> zones. I am not sure this is what discard_alignment is
> >> for ("The discard_alignment parameter indicates how
> >> many bytes the beginning of the partition is offset
> >> from the internal allocation unit's natural alignment").
> > It looks to me like that's what discard_alignment is for.
>
> The word "internal" is not clear to me. Could mean
> internal to partition, or underlying device, the latter
> being the only one meaningful for trimming.
I think its definition could be worded a lot clearer, both with what
the offset is referring to and "internal". It definitely looks to me
like it means the underlying device, in the couple ways Martin
Petersen discussed it.
> > So, if I'm right on this, I won't be able to test a patch including
> > support for discard_alignment!=0 until LVM/dm/kpartx (not sure which)
> > is fixed.
>
> So for now, the safe thing is to keep the check on
> discard_alignment and return "not supported" when
> partition is not properly aligned.
Probably so. With LVM, it sounds like it should work to just ignore
discard_alignment for now, and issue whatever discards there would be
as if its value would be 0. I think most areas of large discarded
areas would be handled, and just the unaligned parts would be ignored.
Areas of size discard_granularity should just be ignored. But, at
least to me, that idea just sounds scary. Even if LVM handles it, if
there's other situations that have a nonzero discard_alignment, who
knows if those virtual or physical storage block would gracefully
handle it too.
> Attached is ioctl.c.patch-v3, which I will push to repo
> next week, unless some new issue emerges.
Sounds good!
_______________________________________________
ntfs-3g-devel mailing list
ntfs-3g-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
