linux-kernel - Re: [osd-dev] [PATCH 1/9] exofs: osd Swiss army knife

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: <496CB322.8010202@panasas.com>
Date:	Tue, 13 Jan 2009 17:28:34 +0200
From:	Benny Halevy <bhalevy@...asas.com>
To:	Jeff Garzik <jeff@...zik.org>, Jamie Lokier <jamie@...reable.org>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Boaz Harrosh <bharrosh@...asas.com>,
	open-osd development <osd-dev@...n-osd.org>,
	Avishay Traeger <avishay@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [osd-dev] [PATCH 1/9] exofs: osd Swiss army knife

On Jan. 13, 2009, 17:17 +0200, Jeff Garzik <jeff@...zik.org> wrote:
> Jamie Lokier wrote:
>> Having one super block would be silly.
> 
> Yep.
> 
> 
>> But aren't most kinds of replication better done behind the OSD level,
>> on the storage fabric?  OSD is all about letting the fabric decide
>> things like allocation and durability strategies after all.
> 
> Probably, but one cannot _assume_ that.  The OSD device might just be a 
> dumb, non-replicated OSD simulator, or in the future, a singleton SATA 
> drive.
> 
> 	Jeff
> 
> 
> 

Alan asked about an _os_ failure.  I consider it different than a disk
level failure which is typically handled by RAID.  At the OS level I'd
care more about the self consistency of the metadata and its corruption
due to the OS (or the OSD) failing to update it atomically.
In exofs's case the metadata in superblock is unexpensive to recover.
It holds the last object ID created.  If, when using it, the filesystem
finds an already existing object it can detect the last object created
using a logarithmic search (or even a linear one assuming the sb is
synced frequently enough).  Therefore I wouldn't spend cycles on
replicating it.

Benny

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