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:	Thu, 13 Mar 2008 01:39:37 -0700 (PDT)
From:	david@...g.hm
To:	Daniel Phillips <phillips@...nq.net>
cc:	David Newall <davidn@...idnewall.com>,
	Chris Friesen <cfriesen@...tel.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Ramback: faster than a speeding bullet

On Thu, 13 Mar 2008, Daniel Phillips wrote:

> On Thursday 13 March 2008 00:55, david@...g.hm wrote:
>> if you are not measuring the time to get from ram to disk (which you are
>> not doing in your ramback device) syncs are meaningless.
>
> There was a time when punchcards ruled and everybody was nervous about
> storing their data on magnetic media.  I remember it well, you may not.
> But you are repeating that bit of history, there is a proverb in there
> somewhere.
>
>>> Why am I reminded of old arguments like "if men were meant to fly, God
>>> would have given them wings"?  Please just give me your microsecond
>>> scale transaction processing solution and I will be impressed and
>>> grateful.  Until then... here is mine.  Service with a smile.
>>
>> if you don't have to worry about unclean shutdowns then your system is not
>> needed. all you need to do is to create a ramdisk that you populate with
>> dd at boot time and save to disk with dd at shutdown. problem solved in a
>> couple lines of shell scripts and no kernel changes needed.
>>
>> if you want the data to be safe in the face of unclean shutdowns and
>> crashes, then you need to figure out how to make the image on disk
>> consistant, and at this point you have basicly said that you don't think
>> that it's a problem. so we're back to what you can do today with a couple
>> lines of scripting.
>
> Feel free.  You use your script, and somebody with a reliable UPS or
> two can use my driver, once it is stabilized of course.  Just don't be
> in business against them if being a few milliseconds slower on the
> uptake means money lost.

so now you are saying that you are faster then a ramdisk?????

either you are completely out of touch or you misunderstood what I was 
saying.

if you have a reliable UPS and are willing to rely on it to save your data 
take the identical hardware to what you are planning to use, but instead 
of using your driver just create a ramdisk and load it on boot and save 
the contents on shutdown.

in this case you are doing zero disk I/O during normal operation, you only 
touch the disk during startup and shutdown.

with your proposal the system will be copying chunks of data from the 
ramdisk to the hard disk at random times, and you are claiming that doing 
so makes you faster then a ramdisk????


I'll say it again. if you trust your UPS and don't care about unclean 
shutdowns (say for example that you trust that linux is just never going 
to crash) there's no need to write parts of the ramdisk to the hard disk 
during normal operation, you can wait until you are told that you are 
going to shutdown to do the data save.

now there's no driver needed, just a couple lines of init scripts.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ