On that today perhaps those thinking of ext4 for production systems - especially shared multiuser systems - should check out CVE-2009-4131 ... CVE-2009-4131: Arbitrary file overwrite in ext4 Insufficient permission checking in the ext4 filesytem could be exploited by local users to overwrite arbitrary files. Ksplice update ID: mfm62pmh 2009/12/11 Ross Walker <rswwalker at gmail.com> > On Dec 10, 2009, at 7:52 PM, Mark Caudill <markca at codelulz.com> wrote: > > > Christopher Chan wrote: > >> Morten Torstensen wrote: > >>> On 08.12.2009 13:34, Chan Chung Hang Christopher wrote: > >>>>> Speaking for me (on Linux systems) on top of LVM on top of md. > >>>>> On IRIX > >>>>> as it was intended. > >>>>> > >>>> That is a disaster combination for XFS even now. You mentioned some > >>>> pretty hefty hardware in your other post... > >>> If XFS doesn't play well with LVM, how can it even be an option? I > >>> couldn't live without LVM... > >>> > >> > >> I meant it in the sense of data guarantee. XFS has a major history of > >> losing data unless used with hardware raid cards that have a bbu > >> cache. > >> That changed when XFS got barrier support. > >> > >> However, anything on LVM be it ext3, ext4 or XFS that has barrier > >> support will not be able to use barriers because device-mapper does > >> not > >> support barriers and therefore, if you use LVM, it better be on a > >> hardware raid array where the card has bbu cache. > > > > Wait, just to be clear, are you saying that all use of LVM is a bad > > idea > > unless on hardware RAID? That's bad it if it's true since it seems > > to me > > that most modern distros like to use LVM by default. Am I missing > > something? > > If you use a leading edge distro then they will most likely be using a > LVM version with barrier support as it was implemented as of > 2.6.29-2.6.30+. > > It should be backported by the next release of CentOS hopefully. > > -Ross > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20091211/94d9cedd/attachment-0004.html>