| 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
| ||
|
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/
Powered by blists - more mailing lists