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

Re: ext3 zerofree option and RedHat back port?



On Wed, Sep 24, 2008 at 09:12:37AM +0100, Ron Yorston wrote:
> "Ulf Zimmermann" <ulf openlane com> wrote:
> >Can anyone tell me if the zerofree option for ext3 has been back ported
> >to RedHat EL4 or EL5?
> 
> I used to maintain backports of zerofree (the kernel patch, not the
> utility) to EL4 and EL5, but since I wasn't actually using them I gave
> up.  The last RPMs I have are from December of last year.  Contact me
> directly if you want them.
> 
> I don't recommend the ext3 patch as it hasn't seen much use.  I regularly
> use the ext2 version (on Fedora 9), but be warned that Ted has expressed
> concerns about it.

I just searched my sent-mail archives for the last 5 years, and I
can't find any references to "zerofree" previous to this mail thread.
Maybe I commented about them under some other name.

Having quickly looked at the ext3 patch here:

       http://osdir.com/ml/file-systems.ext3.user/2006-09/msg00026.html

...the big thing I will note is that if you crash after a file is
deleted, but before the journal transaction is committed, the file may
end up being cleared but not deleted.  This may or may not be
problematic for your appication; in particular, if the file deletion
was implied with the intent of doing an atomic replacement of some
critical file, i.e. such as a vipw script which does:

       cp /etc/passwd /etc/passwd.vipw
       vi /etc/passwd.vipw
       <sanity check /etc/passwd.vipw for correctness>
       # atomically update /etc/passwd
       mv /etc/passwd.vipw /etc/passwd

... and you crash before the transaction is commited but after the
"mv" command has run, you could end up with a partially or completely
zero'ed /etc/passwd file.  Some might call that unfortunate.  :-)

I will admit that the chances of this happening are somewhat remote,
but in terms of potential issues that would have to be fixed before
such a patch could be included in mainline, or before (I suspect) Red
Hat would feel comfortable taking responsibility for their customers'
data after such a patch were committed, that would probably be a real
issue.  The code for supporting the "trim" command could also be used
to implement a proper zero-free command, but it gets tricky, since the
blocks in question would have to be remembered until the commit block
is written out, and then only zero'ed (or trimmed) right after the
commit has happened, but before the pinned block bitmaps are released
(which would allow the block allocator to allocate to the blocks that
had just been released).

						- Ted


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