Re: [PATCH] e2fsck: Discard free data and inode blocks.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 22 Oct 2010, Ric Wheeler wrote:

>  On 10/22/2010 05:12 AM, Lukas Czerner wrote:
> > On Thu, 21 Oct 2010, Andreas Dilger wrote:
> > 
> > > On 2010-10-21, at 08:15, Lukas Czerner wrote:
> > > > In Pass 5 when we are checking block and inode bitmaps we have great
> > > > opportunity to discard free space and unused inodes on the device,
> > > > because bitmaps has just been verified as valid. This commit takes
> > > > advantage of this opportunity and discards both, all free space and
> > > > unused inodes.
> > > > 
> > > > I have added new option '-K' which when set, disables discard. Also when
> > > > the underlying device does not support discard, or BLKDISCARD ioctl
> > > > returns any kind of error, or when some errors occurred in bitmaps, the
> > > > discard is disabled.
> > > I'm always a bit nervous with patches like this, that will prevent data
> > > recovery after an e2fsck run (which seems like the opposite of what we
> > > want from e2fsck).
> > > 
> > > Two suggestions:
> > > - it probably makes sense to disable this by default, and allow it to be
> > >    specified on the command-line and e2fsck.conf
> > > - should we really have a short option, or a "-E discard" and "-E
> > > nodiscard"
> > >    options, which allow us to change the default easily at some later time
> > >    (which we can't do with a single -K flag)
> > Right, I agree it would be probably better to disable this by default.
> > 
> > 
> 
> If we do disable it by default, I think that we might also want to be
> consistent and disable the discard support in mkfs by default as well?
> 
> thanks!
> 
> Ric
> 

I think that this will not be necessary. There is a concern that it might
prevent data recovery after fsck because it might be already discarded
(some weird fs corruption?) in pass 5. However in my opinion this is a
very small window (if there even is any), because we have already passed
check 1-4 and we have just confirmed that group descriptors should be ok.
But when there is an even slight chance this might happen I would suggest
that we really disable it by default (at least for a while - we will see
then).

On the other hand there is nothing to be afraid of in the case of mkfs,
because we can not possibly lose any relevant data, because discard is
done before the filesystem gets created.

-Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux