[EMAIL PROTECTED] (Jeff Davis) wrote:
> On Wed, 2006-09-06 at 18:55 -0400, Chris Browne wrote:
>> [EMAIL PROTECTED] (Jeff Davis) writes:
>> >> > Do you see an advantage in using LFS for PostgreSQL?
>> >> 
>> >> Hey guys - I think the original poster only meant to suggest that it
>> >> was *interesting*... :-)
>> >> 
>> >
>> > I see, my mistake.
>> >From a reliability perspective, I can see some value to it...  
>> I have seen far too many databases corrupted by journalling gone bad
>> in the past year...  :-(
> Can you elaborate a little? Which filesystems have been problematic?
> Which filesystems are you more confident in?

Well, more or less *all* of them, on AMD-64/Linux.

The "pulling the fibrechannel cable" test blew them all.  XFS, ext3,
JFS.  ReiserFS was, if I recall correctly, marginally better, but only

On AIX, we have seen JFS2 falling over when there were enough levels
of buffering in the way on disk arrays.

>> > And if there is an improvement, shouldn't that be a project for
>> > something like Linux, where other databases could also benefit? 
>> > It could just be implemented as a database-specific filesystem.
>> The classic problem with log structured filesystems is that
>> sequential reads tend to be less efficient than in overwriting
>> systems; perhaps if they can get "vacuuming" to be done frequently
>> enough, that might change the shape of things.
>> That would be a relevant lesson that _we_ have discovered that is
>> potentially applicable to filesystem implementors.
>> And I don't consider this purely of academic interest; the ability to:
>>  a) Avoid the double writing of journalling, and
>>  b) Avoid the risks of failures due to misordered writes
>> are both genuinely valuable.
> Right, LFS is promising in a number of ways. I've read about it in
> the past, and it would be nice if this NILFS implementation sparks
> some new research in the area.


I don't see it being a "production-ready" answer yet, but yeah, I'd
certainly like to see the research continue.  A vital problem is in
the area of vacuuming; there may be things to be learned in both
output = reverse("moc.liamg" "@" "enworbbc")
Health is merely the slowest possible rate at which one can die.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to