linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benny Halevy <bhalevy@panasas.com>
To: Jeff Garzik <jeff@garzik.org>, Jamie Lokier <jamie@shareable.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Boaz Harrosh <bharrosh@panasas.com>,
	open-osd development <osd-dev@open-osd.org>,
	Avishay Traeger <avishay@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [osd-dev] [PATCH 1/9] exofs: osd Swiss army knife
Date: Tue, 13 Jan 2009 17:28:34 +0200	[thread overview]
Message-ID: <496CB322.8010202@panasas.com> (raw)
In-Reply-To: <496CB076.8080002@garzik.org>

On Jan. 13, 2009, 17:17 +0200, Jeff Garzik <jeff@garzik.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



      reply	other threads:[~2009-01-13 15:28 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-16 14:48 [PATCHSET 0/9] exofs (was osdfs) Boaz Harrosh
2008-12-16 14:52 ` [PATCH 1/9] exofs: osd Swiss army knife Boaz Harrosh
2008-12-29 20:29   ` Andrew Morton
2008-12-31 15:33     ` Boaz Harrosh
2008-12-31 19:26       ` Andrew Morton
2009-01-01 14:44         ` Boaz Harrosh
2009-01-02 16:52     ` Pavel Machek
2009-01-04  8:43       ` Boaz Harrosh
2009-01-04 20:03         ` Pavel Machek
2009-01-05  9:01           ` Boaz Harrosh
2009-01-05  9:36             ` Pavel Machek
2008-12-16 15:15 ` Boaz Harrosh
2008-12-16 15:17 ` [PATCH 2/9] exofs: file and file_inode operations Boaz Harrosh
2008-12-29 20:34   ` Andrew Morton
2008-12-31 15:36     ` Boaz Harrosh
2008-12-16 15:21 ` [PATCH 3/9] exofs: symlink_inode and fast_symlink_inode operations Boaz Harrosh
2008-12-29 20:35   ` Andrew Morton
2008-12-16 15:22 ` [PATCH 4/9] exofs: address_space_operations Boaz Harrosh
2008-12-29 20:45   ` Andrew Morton
2008-12-31 15:35     ` Boaz Harrosh
2008-12-16 15:28 ` [PATCH 5/9] exofs: dir_inode and directory operations Boaz Harrosh
2008-12-29 20:47   ` Andrew Morton
2008-12-31 15:33     ` Boaz Harrosh
2008-12-16 15:31 ` [PATCH 6/9] exofs: super_operations and file_system_type Boaz Harrosh
2008-12-17 22:23   ` Marcin Slusarz
2008-12-18  8:41     ` Boaz Harrosh
2008-12-29 20:50   ` Andrew Morton
2008-12-16 15:33 ` [PATCH 7/9] exofs: mkexofs Boaz Harrosh
2008-12-29 20:14   ` Andrew Morton
2008-12-31 15:19     ` Boaz Harrosh
2008-12-31 15:57       ` James Bottomley
2009-01-01  9:22         ` [osd-dev] " Benny Halevy
2009-01-01  9:54           ` Jeff Garzik
2009-01-01 14:23             ` Benny Halevy
2009-01-01 14:28               ` Matthew Wilcox
2009-01-01 18:12               ` Jörn Engel
2009-01-01 23:26           ` J. Bruce Fields
2009-01-02  7:14             ` Benny Halevy
2009-01-04 15:20         ` Boaz Harrosh
2009-01-04 15:38           ` Christoph Hellwig
2009-01-12 18:12           ` James Bottomley
2009-01-12 19:23             ` Jeff Garzik
2009-01-12 19:56               ` James Bottomley
     [not found]               ` <1231790190.15161.29.camel@localhost.localdomain>
2009-01-12 20:22                 ` Jeff Garzik
2009-01-12 23:25                   ` James Bottomley
2009-01-13 13:03                     ` [osd-dev] " Benny Halevy
2009-01-13 13:24                       ` Jeff Garzik
2009-01-13 13:32                         ` Benny Halevy
2009-01-13 13:44                     ` Jeff Garzik
2009-01-13 14:03                       ` Alan Cox
2009-01-13 14:17                         ` Jeff Garzik
2009-01-13 16:14                           ` Alan Cox
2009-01-13 17:21                             ` Boaz Harrosh
2009-01-21 18:13                               ` Jeff Garzik
2009-01-21 18:44                                 ` Boaz Harrosh
2009-01-12 22:48             ` Jamie Lokier
2009-01-06  8:40         ` Andreas Dilger
2008-12-31 19:25       ` Andrew Morton
2009-01-01 13:33         ` Boaz Harrosh
2009-01-02 22:46           ` James Bottomley
2009-01-04  8:59             ` Boaz Harrosh
2008-12-16 15:36 ` [PATCH 8/9] exofs: Documentation Boaz Harrosh
2008-12-18  7:47   ` Pavel Machek
2008-12-18  8:32     ` Boaz Harrosh
2008-12-16 15:38 ` [PATCH 9/9] fs: Add exofs to Kernel build Boaz Harrosh
     [not found] ` <4947C624.3050602@panasas.com>
2009-01-07 15:47   ` [osd-dev] [PATCH 1/9] exofs: osd Swiss army knife Benny Halevy
2009-01-13 13:55     ` Alan Cox
2009-01-13 14:43       ` Boaz Harrosh
2009-01-13 14:52         ` Boaz Harrosh
2009-01-13 15:09       ` Jamie Lokier
2009-01-13 15:17         ` Jeff Garzik
2009-01-13 15:28           ` Benny Halevy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=496CB322.8010202@panasas.com \
    --to=bhalevy@panasas.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=avishay@gmail.com \
    --cc=bharrosh@panasas.com \
    --cc=jamie@shareable.org \
    --cc=jeff@garzik.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=osd-dev@open-osd.org \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).