| 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, 6 Nov 2006 22:19:03 +0100 From: Jörn Engel <joern@...nheim.fh-wedel.de> To: Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz> Cc: linux-kernel@...r.kernel.org Subject: Re: New filesystem for Linux On Sat, 4 November 2006 19:50:01 +0100, Mikulas Patocka wrote: > > LFS fragments data by design ... it can't write to already allocated > space, so if you write to the middle of LFS directory, it will allocate > new block, new indirect pointers to that directory, new block in inode > table etc. Based on the assumption that reads don't matter, which proved wrong. Yes. Your allocation strategy sounds fairly good. I'm not a benchmark person, so I can only tell horrible from decent, not decent from good. Your benchmarks speak for themselves, so I guess it is more than just decent. However, going back to crash counts and transaction counts, I still don't understand why you don't just have two checkpoints (or any other objects, if you don't like the name) with a 64bit version number each that you alternately write for sync(). You seem to have that concept for managing free space, just not to manage valid data. What is the difference? Jörn -- Courage is not the absence of fear, but rather the judgement that something else is more important than fear. -- Ambrose Redmoon - 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