[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
marginally.
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.
Indeed.
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
directions.
--
output = reverse("moc.liamg" "@" "enworbbc")
http://linuxdatabases.info/info/fs.html
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
match
