Re: [tlug] Raid5 box & backup

[Christian Horn <chorn@example.com>]

On Mon, May 26, 2008 at 10:37:50AM +0900, Curt Sampson wrote:
> On 2008-05-26 02:37 +0200 (Mon), Christian Horn wrote:
> 
> > Case a, plain nfs, unencrypted.
> > Pure nfs is used here, usual small files stored on the 2 datastores.
> > pros: highest fault tolerence, rsync efficient because it syncs single 
> >   files
> 
> While you're right about the rsync, I doubt that this would have better
> fault tolerence than a journaling filesystem over a network-exported
> block device (e.g., iSCSI or that network-exported ATA thing).

The journaling filesystem is another layer and stores everything in the
container-file while nfs/smb would work filewise. Actually one could
do some crash-testing of the 2 scenarios with emulated/virtualized
systems, could be interesting.


> And come to think of it, if you had, say, a dozen block devices each
> each backed by its own file and used the concatenation of these devices
> as a single filesystem, you might well get much better rsync behaviour
> (assuming that the timestamps work as they should). Even with a standard
> FFS-style FS, you'd only have to sync the files covering the cylinder
> groups you'd touched, and if you used something like Berkeley's LFS,
> you'd only be updating one file if you'd only made a few changes.

Indeed, nice idea, that way rsync would finish faster.
The "combine blocks"-software had to be evailable on mac/win/linux in
this case thou, also its basically just concatting into a big block-
device.
Also rsync could probably be reworked to handle big file in breaking 
them into pieces and checksuming/transferring if needed those.


> > Case b, plain nfs, files ecrypt encrypted.
>
> Got a reference for ecrypt? You may have the issue, if it's what I think
> it is, that it exposes things such as file counts, sizes, and update
> times.

Thats right, those things are unveiled.
http://ecryptfs.sourceforge.net/


Christian