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]

Message-ID: <20080310093737.3c1e938a@core>
Date:	Mon, 10 Mar 2008 09:37:37 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Daniel Phillips <phillips@...nq.net>
Cc:	Grzegorz Kulewski <kangur@...com.net>, linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Ramback: faster than a speeding bullet

> Usual block device semantics are preserved so long as UPS power does
> not run out before emergency writeback completes.  It is not possible
> to order writes to the backing store and still deliver ramdisk level
> write latency to the application.

Why - your chunks simply become a linked list in write barrier order.
Solve your bitmap sweep cost as well. As you are already making a copy
before going to backing store you don't have the internal consistency
problems of further writes during the I/O.

Yes you may need to throttle in the specific case of having too many
copies of pages sitting in the queue - but surely that would be the set of
pages that are written but not yet committed from a previous store
barrier ?

BTW: I'm also curious why you made it a block device. What does that
offer over say ramfs + dnotify and a userspace daemon or perhaps for big
files to work smoothly a ramfs variant that keeps dirty bitmaps on file
pages. That way write back would be file level and while you might lose
changesets that have not been fsync()'d your underlying disk fs would
always be coherent.

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