lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 31 Jul 2006 23:32:28 -0500
From:	David Masover <ninja@...phack.com>
To:	David Lang <dlang@...italinsight.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"expressed
 by kernelnewbies.org regarding reiser4 inclusion]

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.

> 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.

Very useful for a laptop -- I used to do this in Linux by using Reiser4, 
setting the disk to spin down, and letting lazy writes do their thing, 
but I didn't have enough RAM, and there's always the possibility of 
losing data.  But leaving the disk off is nice, because in the event of 
sudden motion, it's safer that way.  Besides, most hardware gets 
designed for That Other OS, which doesn't support any kind of Laptop 
Mode, so it's nice to be able to enforce this at a hardware level, in a 
safe way.

> I've heard to many fancy-sounding drive technologies that never hit the 
> market, I'll wait until thye are actually available before I start 
> counting on them for anything  (let alone design/run a filesystem that 
> requires them :-)

Or even remember their names.

> 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...

-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ