Hi, Both GFS1 and GFS2 are safe from this problem since neither of them use barriers. Instead we do a flush at the critical points to ensure that all data is on disk before proceeding with the next stage. Using barriers can improve performance in certain cases, but we've not yet implemented them in GFS2, Steve. On Mon, 2008-03-31 at 12:46 +0200, Mathieu Avila wrote: > Hello all again, > > More information on this topic: > http://lkml.org/lkml/2007/5/25/71 > > I guess the problem also applies to GFSS2. > > -- > Mathieu > > Le Fri, 28 Mar 2008 15:34:58 +0100, > Mathieu Avila <mathieu.avila@xxxxxxxxxxxx> a écrit : > > > Hello GFS team, > > > > Some recent kernel developements have brought IO barriers into the > > kernel to prevent corruptions that could happen when blocks are being > > reordered before write, by the kernel or the block device itself, just > > before an electrical power failure. > > (on high-end block devices with UPS or NVRAM, those problems cannot > > happen) > > Some file systems implement them, notably ext3 and XFS. It seems to me > > that GFS1 has no such thing. > > > > Do you plan to implement it ? If so, could the attached patch do the > > work ? It's incomplete : it would need a global tuning like > > fast_stafs, and a mount option like it's done for ext3. The code is > > mainly a copy-paste from JBD, and does a barrier only for journal > > meta-data. (should i do it for other meta-data ?) > > > > Thanks, > > > > -- > > Mathieu > > > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
