On Thu, Feb 5, 2009 at 5:18 PM, Theodore Tso <[email protected]> wrote:
> On Thu, Feb 05, 2009 at 05:01:01PM -0500, Greg Freemyer wrote:
>> > It also has absolutely nothing to do with the original thread, which
>> > was block numbers which are far outside the range of valid block
>> > numbers given the size of the block device. :-)
>>
>> The subject was "return blocks outside filesystem".
>
> Yes, it's clear you didn't read the e-mail thread, but rather just
> keyed off the subject line. :-)
>
>> In a thin-provisioning environment I'd argue that unmapped sectors are
>> "outside the filesystem". :)
>>
>> Unfortunately, I can't get anyone else to see the world from my
>> apparently unique perspective. :(
>
> If you don't like this, don't use thin-provisioned devices. Again, I
> don't see the likely scenario where your fears are likely to be a
> factor in a real world scenario. If there are bugs in the
> thin-provisioned devices, people shouldn't use them. Given that we
> are conservative about when we tell thin-provisioned devices that
> blocks are no longer in use (i.e., on journal commits, and if we
> crash, just don't tell the device the blocks can be reused), what's
> the problem that you're worried about? How does it occur in real
> life?
>
> It's hard to defend against a theoretical problem when you only give
> vague fears about how it might be triggered...
>
> - Ted
Ted,
I just have a very fundamental issue with a storage spec that allows
random garbage to be returned in response to a read request with no
signaling mechanism included to notify the kernel that it is reading
trash. Ric has told me that in the real world, storage vendors are
likely to return a well defined pattern (nulls, etc.) in response to
reads of these unmapped sectors. If true, why not have the spec say
so.
Or have some way to communicate to the kernel which sectors are
reliable (mapped) vs. unreliable (unmapped).
On the one hand the whole purpose of the SCSI DIF/DIX extension is to
ensure that the data being read from a scsi device is the exact data
that was written, but the thin-provisioning specs go in the opposite
direction and allow complete garbage to be returned with no signaling
mechanism to allow the kernel to even conceivably find out.
Instead of focusing on the negative, I'll reword my issue to discuss
how unmapped sector knowledge (if available) could be used to
_improve_ the current functionality of a filesystem:
==> Positive spin on how knowledge of which sectors are unmapped could
improve filesystem reliability
The original email discussed pointers that in someway became corrupted
to point at blocks which NEVER contained valid data. Since the data
is outside of the overall range of data blocks, it can be identified
and both the kernel and userspace can be prevented from relying on
what would obviously be trash.
Whatever mechanism caused the bmap pointers to point outside the
overall range of the filesystem, I assume could just as easily cause
the those pointers to point at unmapped sectors.
If the SCSI / ATA specs were enhanced to somehow notify the kernel
when a read of these unmapped sectors occurred, then both the kernel
and userspace could be protected from relying on this potential trash
as well.
FYI: I've tried to find a way to send my comments to the T10
committee, but I have not found a way to do that since the spec is not
in a "public comment" period at present.
Greg
--
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf
The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
Greg Freemyer <[email protected]> writes:
> I just have a very fundamental issue with a storage spec that allows
> random garbage to be returned in response to a read request with no
> signaling mechanism included to notify the kernel that it is reading
> trash. Ric has told me that in the real world, storage vendors are
> likely to return a well defined pattern (nulls, etc.) in response to
> reads of these unmapped sectors. If true, why not have the spec say
> so.
More flexibility for implementations. It means implementations do not
have to check for the validity of read requests. This can sometimes
speed up things, save (non volatile) memory, save disk syncs, save
global locks for mapping updates, ...
Imagine if the C standard would require that accessing a invalid
pointer would abort the program. Suddenly every pointer access would
have to be validated in case the pointer is invalid but accidentally
points to some (for the cpu) valid address.
> Or have some way to communicate to the kernel which sectors are
> reliable (mapped) vs. unreliable (unmapped).
>
> On the one hand the whole purpose of the SCSI DIF/DIX extension is to
> ensure that the data being read from a scsi device is the exact data
> that was written, but the thin-provisioning specs go in the opposite
> direction and allow complete garbage to be returned with no signaling
> mechanism to allow the kernel to even conceivably find out.
>
> Instead of focusing on the negative, I'll reword my issue to discuss
> how unmapped sector knowledge (if available) could be used to
> _improve_ the current functionality of a filesystem:
>
> ==> Positive spin on how knowledge of which sectors are unmapped could
> improve filesystem reliability
Isn't it more advantageous for wear leveling? The more unused blocks a
device has the better it can level wear and thereby extend the
lifetime of the device.
> The original email discussed pointers that in someway became corrupted
> to point at blocks which NEVER contained valid data. Since the data
> is outside of the overall range of data blocks, it can be identified
> and both the kernel and userspace can be prevented from relying on
> what would obviously be trash.
>
> Whatever mechanism caused the bmap pointers to point outside the
> overall range of the filesystem, I assume could just as easily cause
> the those pointers to point at unmapped sectors.
>
> If the SCSI / ATA specs were enhanced to somehow notify the kernel
> when a read of these unmapped sectors occurred, then both the kernel
> and userspace could be protected from relying on this potential trash
> as well.
At least there should be a scsi reply for this. The use of which could
still be optional. So either an error or any data could be
valid. Obviously requiring a proper error would be better for the
user.
> FYI: I've tried to find a way to send my comments to the T10
> committee, but I have not found a way to do that since the spec is not
> in a "public comment" period at present.
>
> Greg
MfG
Goswin