linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ric Wheeler <rwheeler@redhat.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Goswin von Brederlow <goswin-v-b@web.de>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [RFC] ext4_bmap() may return blocks outside filesystem
Date: Sat, 07 Feb 2009 13:20:48 -0500	[thread overview]
Message-ID: <498DD100.3000700@redhat.com> (raw)
In-Reply-To: <20090207155151.GE29213@mini-me.lan>

Theodore Tso wrote:
> On Sat, Feb 07, 2009 at 02:27:31PM +0100, Goswin von Brederlow wrote:
>   
>> I see the following scenario:
>>
>> 1) The filesystem / thin-provision gets corrupted somehow. fs bug,
>> hardware, whatever.
>>
>> 2) The thin-provision thinks a block is free while the FS thinks it is
>> in use. Make it a meta data block so it really matters.
>>
>> 3) The thin-provision still has the mapping and data of the block and
>> hasn't reused the block yet. On read the device will return the
>> correct data as long as the block is not reused. This seems to be a
>> valid implementation for a thin-provision device.
>>     
>
> That's highly unlikely, actually.  Once you tell the thin-provisioning
> device that the block is not in use, they will delete the mapping from
> their mapping structures.  So it's highly unlikely you will be able to
> recover once you send the TRIM command.
>   

For SCSI, that is actually not unlikely since the spec does not require 
you to actually do anything with the command - they can simply be 
ignored, so the original data will stay there unchanged.

If it is unmapped (in SCSI speak), and you read that sector, the storage 
device must return consistent contents for each subsequent read.

Ric

>   
>> 4) fsck will find no error but future writes will reuse the block on
>> the thin-provision device overwriting the data and causing
>> catastrophic FS corruption.
>>     
>
> The way this can happen today is if the bitmap block gets corrupted,
> and so a block which is in use gets used by another inode.  So now you
> have a filesystem block overwritten by a data block from an inode ---
> so you have potentially catastrophic FS corruption, even before you
> issue the ATA TRIM command.  This can happen to day, and in practice,
> it is extremely rare.  So permit me for being highly dubious about
> your claim this is going to happen more often with thin-provisioned
> devices.
>
>   
>> So I think a fsck pass to check FS used blocks against hardware used
>> blocks is essential if the FS does support thin-provisioned devices.
>>     
>
> The filesystem might not even know whether or not a thin-provisioned
> device is in use.  The OS may not even know whether the device is
> thin-provisioned.  So ultiamtely, it's not up to the FS...
>
> 		      		       	      - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   


      reply	other threads:[~2009-02-07 18:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-05 12:03 [RFC] ext4_bmap() may return blocks outside filesystem Thiemo Nagel
2009-02-05 13:49 ` Theodore Tso
2009-02-05 15:22   ` Greg Freemyer
2009-02-05 15:39     ` Ric Wheeler
2009-02-05 16:48       ` Theodore Tso
2009-02-05 22:01         ` Greg Freemyer
2009-02-05 22:18           ` Theodore Tso
2009-02-07 13:27             ` Goswin von Brederlow
2009-02-07 15:51               ` Theodore Tso
2009-02-07 18:20                 ` Ric Wheeler [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=498DD100.3000700@redhat.com \
    --to=rwheeler@redhat.com \
    --cc=goswin-v-b@web.de \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).