[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.63.0607312142020.15179@qynat.qvtvafvgr.pbz>
Date: Mon, 31 Jul 2006 21:53:55 -0700 (PDT)
From: David Lang <dlang@...italinsight.com>
To: David Masover <ninja@...phack.com>
cc: Nate Diller <nate.diller@...il.com>,
Adrian Ulrich <reiser4@...nkenlights.ch>,
"Horst H. von Brand" <vonbrand@....utfsm.cl>, ipso@...ppymail.ca,
reiser@...esys.com, lkml@...productions.com, jeff@...zik.org,
tytso@....edu, linux-kernel@...r.kernel.org,
reiserfs-list@...esys.com
Subject: Re: Solaris ZFS on Linux [Was: Re: the " 'official' point of
view"expressedby kernelnewbies.org regarding reiser4 inclusion]
On Mon, 31 Jul 2006, David Masover wrote:
> David Lang wrote:
>> On Mon, 31 Jul 2006, David Masover wrote:
>>
>>> Oh, I'm curious -- do hard drives ever carry enough battery/capacitance to
>>> cover their caches? It doesn't seem like it would be that hard/expensive,
>>> and if it is done that way, then I think it's valid to leave them on. You
>>> could just say that other filesystems aren't taking as much advantage of
>>> newer drive features as Reiser :P
>>
>> there are no drives that have the ability to flush their cache after they
>> loose power.
>
> Aha, so back to the usual argument: UPS! It takes a fraction of a second to
> flush that cache.
which does absolutly no good if someone trips over the power cord, the fuse
blows in the power supply, someone yanks the drive out of the hot-swap bay, etc.
>> now, that being said, /. had a story within the last couple of days about
>> hard drive manufacturers adding flash to their hard drives. they may be
>> aiming to add some non-volitile cache capability to their drives, although
>> I didn't think that flash writes were that fast (needed if you dump the
>> cache to flash when you loose power), or that easy on power (given that you
>> would first loose power), and flash has limited write cycles (needed if you
>> always use the cache).
>
> But, the point of flash was not to replace the RAM cache, but to be another
> level. That is, you have your Flash which may be as fast as the disk, maybe
> faster, maybe less, and you have maybe a gig worth of it. Even the bloatiest
> of OSes aren't really all that big -- my OS X came installed, with all kinds
> of apps I'll never use, in less than 10 gigs.
>
> And I think this story was awhile ago (a dupe? Not surprising), and the
> point of the Flash is that as long as your read/write cache doesn't run out,
> and you're still in that 1 gig of Flash, you're a bit safer than the RAM
> cache, and you can also leave the disk off, as in, spinned down. Parked.
as I understand it flash reads are fast (ram speeds), but writes are pretty slow
(comparable or worse to spinning media)
writing to a ram cache, but having a flash drive behind it doesn't gain you any
protection. and I don't think you need it for reads
>> external battery backed cache is readily available, either on high-end raid
>> controllers or as seperate ram drives (and in raid array boxes), but
>> nothing on individual drives.
>
> Ah. Curses.
>
> UPS, then. If you have enough time, you could even do a Software Suspend
> first -- that way, when power comes back on, you boot back up, and if it's
> done quickly enough, connections won't even be dropped...
remember, it can take 90W of power to run your CPU, 100+ to run your video card,
plus everything else. even a few seconds of power for this is a very significant
amount of energy storage.
however, I did get a pointer recently at a company makeing super-high capcity
caps, up to 2600F (F, not uF!) in a 138mmx tall 57mm dia cyliner, however it
only handles 2.7v (they have modules that handle higher voltages available)
http://www.maxwell.com/ultracapacitors/index.html
however I don't see these as being standard equipment in systems or on drives
anytime soon
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists