linux-kernel - Re: [ANNOUNCE] Ramback: faster than a speeding bullet

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:	Sat, 15 Mar 2008 13:05:59 -0800
From:	Daniel Phillips <phillips@...nq.net>
To:	Pavel Machek <pavel@....cz>
Cc:	David Newall <davidn@...idnewall.com>, david@...g.hm,
	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 Saturday 15 March 2008 13:26, Pavel Machek wrote:
> On Thu 2008-03-13 12:03:03, Daniel Phillips wrote:
> > On Thursday 13 March 2008 12:50, David Newall wrote:
> > > Daniel Phillips wrote:
> > > > The period where you cannot access the data is downtime.  If your script
> > > > just does a cp from a disk array to the ram device you cannot just read
> > > > from the backing store in that period because you will need to fail over
> > > > to the ramdisk at some point, and you cannot just read from the ramdisk
> > > > because it is not populated yet.
> > > 
> > > Wouldn't a raid-1 set comprising disk + ramdisk do that with no downtime?
> > 
> > In raid1, write completion has to wait for write completion on all
> > mirror members, so writes run at disk speed.  Reads run at ramdisk
> > speed, so your proposal sounds useful, but ramback aims for high
> > write performance as well.
> 
> raid1 + kflushd tweak?
> special raid1 mode that signals completion when it hits _one_ of the
> drives, and does sync when the slower drive is idle?

Feel free :-)

This is very close to how ramback already works.  One subtlety is that
ramback does not write twice from the same application data source,
which could allow the data on the backing device to differ from the
ramdisk if the user changes it during the write.  I don't know how
important it is to protect against this bug actually, but there you
have it.  Ramback can easily to changed to write twice from the same
source just like a raid1 (in fact it originally was that way) which
would make it even more like raid1.

Adding ramback-like functionality to raid1 would be a nice
contribution.  I would fully support that but I do not have time to do
it myself.

Daniel
--
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/