linux-kernel - Re: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems

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: <45804E3C.9020105@cfl.rr.com>
Date:	Wed, 13 Dec 2006 14:02:20 -0500
From:	Phillip Susi <psusi@....rr.com>
To:	Nikolai Joukov <kolya@...sunysb.edu>
CC:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	unionfs@...er.fsl.cs.sunysb.edu, fistgen@...er.fsl.cs.sunysb.edu
Subject: Re: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems

Nikolai Joukov wrote:
> replication.  In case of RAID4 and RAID5-like configurations, RAIF performed
> about two times *better* than software RAID and even better than an Adaptec
> 2120S RAID5 controller.  This is because RAIF is located above file system
> caches and can cache parity as normal data when needed.  We have more
> performance details in a technical report, if anyone is interested.

This doesn't make sense to me.  You do not want to cache the parity 
data.  It only needs to be used to validate the data blocks when the 
stripe is read, and after that, you only want to cache the data, and 
throw out the parity.  Caching the parity as well will pollute the cache 
and thus, should lower performance due to more important data being 
thrown out.




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