[Top] [All Lists]

Re: External log and possibilities.

To: Keith Matthews <keith_m@xxxxxxxxxxxxxxxxxxx>
Subject: Re: External log and possibilities.
From: "Martin K. Petersen" <mkp@xxxxxxxxxxxxx>
Date: 20 Jul 2001 08:24:41 -0400
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20010720073356.A02EB125E6@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Organization: Linuxcare, Inc.
References: <001d01c110e0$78a0b000$3c532840@towerpc> <20010720073356.A02EB125E6@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
>>>>> "Keith" == Keith Matthews <keith_m@xxxxxxxxxxxxxxxxxxx> writes:

>> I want wondering if anyone here was aware of non-volatile RAM
>> devices 128m-1g and would such a device work with Linux and then
>> allow you to use an external log to read/write to them.  I would
>> expect that if it's based on SDRAM, etc it would make for some
>> interesting performance gains.

>> Anyone have any thoughts on this?

Logging to NVRAM is quite common on other systems (Sun PrestoServe,
Compaqdecital has one, NetApp, and most hardware RAID solutions).
Unfortunately, good boards are both expensive and hard to come by.

I've tried to find one on several occasions, and I know Stephen
Tweedie has done the same for his ext3 work.

Another option is to use a solid state disk.  But that will cost you
an arm and a leg.

Keith> If you are talking about Flash then it has the limitation of a
Keith> fairly small max numbr of write cycles. I have heard 100,000
Keith> quoted - not much for a busy fileserver.

It is correct that flash has limitations - often in the order of
magnitude you quote there.

However, NVRAM boards for logging use batteries to refresh regular
memory, and consequently they don't suffer from the same problems.
You need to get power back on the box within too long, though.  On
most systems within a 2-3 day period.

For people interested in experimenting with the performance gains from
using a memory based log device, I recommend you put the log on a
ramdisk (Only for testing. Kids, do not try this at home!).  

Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@xxxxxxxxxxxxx, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

<Prev in Thread] Current Thread [Next in Thread>