linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: Hubert Kario <hka@qbs.com.pl>
Cc: Martin Steigerwald <Martin@lichtvoll.de>,
	linux-btrfs@vger.kernel.org,
	Kaspar Schleiser <kaspar@schleiser.de>
Subject: Re: kernel 3.3.4 damages filesystem (?)
Date: Thu, 10 May 2012 21:15:30 +0100	[thread overview]
Message-ID: <20120510201530.GS8938@carfax.org.uk> (raw)
In-Reply-To: <3868267.PxBJ7yCiiK@bursa22>

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

On Thu, May 10, 2012 at 09:43:58PM +0200, Hubert Kario wrote:
> On Thursday 10 of May 2012 12:40:49 Martin Steigerwald wrote:
> > Am Mittwoch, 9. Mai 2012 schrieb Kaspar Schleiser:
> > > Hi,
> > > 
> > > On 05/08/2012 10:56 PM, Roman Mamedov wrote:
> > > > Regarding btrfs, AFAIK even "btrfs -d single" suggested above works
> > > > not "per file", but per allocation extent, so in case of one disk
> > > > failure you will lose random *parts* (extents) of random files,
> > > > which in effect could mean no file in your whole file system will
> > > > remain undamaged.
> > > 
> > > Maybe we should evaluate the possiblility of such a "one file gets on
> > > one disk" feature.
> > > 
> > > Helmut Hullen has the use case: Many disks, totally non-critical but
> > > nice-to-have data. If one disk dies, some *files* should lost, not some
> > > *random parts of all files*.
> > > 
> > > This could be accomplished by some userspace-tool that moves stuff
> > > around, combined with "file pinning"-support, that lets the user make
> > > sure a specific file is on a specific disk.
> > 
> > Yeah, basically I think thats the whole point Helmut is trying to make.
> > 
> > I am not sure whether that should be in userspace. It could be just an
> > allocation mode like "raid0" or "single". Such as "single" as in one file
> > is really on one disk and thats it.
> 
> I was thinking that "linear" would be good name for old style allocator.

   Please do distinguish between the replication level (e.g. "single",
"RAID-1") and the allocator algorithm. These are distinct. Also, note
that both of those work on the scale of chunks/block groups. There is
a further consideration, which is the allocation of file data to block
groups, which is a whole different thing again (and not something I
know a great deal about), but which will also affect the desired
outcome quite a lot.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- Anyone who claims their cryptographic protocol is secure is ---   
         either a genius or a fool.  Given the genius/fool ratio         
                 for our species,  the odds aren't good.                 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

  reply	other threads:[~2012-05-10 20:15 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-07 10:46 kernel 3.3.4 damages filesystem (?) Helmut Hullen
2012-05-07 10:58 ` Fajar A. Nugraha
2012-05-07 12:06   ` Helmut Hullen
2012-05-07 10:59 ` Hugo Mills
2012-05-07 12:15   ` Helmut Hullen
2012-05-07 13:34   ` Helmut Hullen
2012-05-07 14:05     ` Hugo Mills
2012-05-07 16:36       ` Helmut Hullen
2012-05-07 17:13         ` Felix Blanke
2012-05-07 17:52           ` Helmut Hullen
2012-05-07 18:00             ` Hugo Mills
2012-05-07 18:25               ` Helmut Hullen
2012-05-07 18:44                 ` Hugo Mills
2012-05-09 13:04                   ` failed disk (was: kernel 3.3.4 damages filesystem (?)) Helmut Hullen
2012-05-09 13:19                     ` Hugo Mills
2012-05-09 14:25               ` Helmut Hullen
2012-05-09 14:37                 ` Hugo Mills
2012-05-09 15:14                   ` failed disk Helmut Hullen
2012-05-09 15:33                     ` Hugo Mills
2012-05-09 18:49                       ` Helmut Hullen
2012-05-09 16:13                   ` failed disk (was: kernel 3.3.4 damages filesystem (?)) Ilya Dryomov
2012-05-10  2:49                   ` failed disk Helmut Hullen
2012-05-07 19:30             ` kernel 3.3.4 damages filesystem (?) Daniel Lee
2012-05-07 20:21               ` Helmut Hullen
2012-05-07 20:51                 ` Daniel Lee
2012-05-07 21:17                   ` Helmut Hullen
2012-05-07 21:27                     ` cwillu
2012-05-07 22:07                 ` Martin Steigerwald
2012-05-08  7:39                   ` Helmut Hullen
2012-05-08  7:44                     ` Fajar A. Nugraha
2012-05-08 10:00                       ` Helmut Hullen
2012-05-08 10:41                         ` Clemens Eisserer
2012-05-08 13:13                           ` Helmut Hullen
2012-05-08 13:44                             ` Felix Blanke
2012-05-08 13:52                               ` Hugo Mills
2012-05-08 16:53                               ` Helmut Hullen
2012-05-08 17:24                                 ` Felix Blanke
2012-05-08 18:29                                   ` Helmut Hullen
2012-05-08 18:41                                     ` Felix Blanke
2012-05-08 19:12                                       ` David Sterba
2012-05-08 19:34                                       ` Helmut Hullen
2012-05-08 20:02                                         ` Hugo Mills
2012-05-08 20:19                                           ` Helmut Hullen
2012-05-08 20:56                                             ` Roman Mamedov
2012-05-09 14:46                                               ` Kaspar Schleiser
2012-05-10 10:40                                                 ` Martin Steigerwald
2012-05-10 11:55                                                   ` feature request (was: kernel 3.3.4 damages filesystem (?)) Helmut Hullen
2012-05-10 19:43                                                   ` kernel 3.3.4 damages filesystem (?) Hubert Kario
2012-05-10 20:15                                                     ` Hugo Mills [this message]
2012-05-10 20:23                                                       ` Hubert Kario
2012-05-08 21:42                         ` Hubert Kario
2012-05-07 12:53 ` Liu Bo
2012-05-09 17:32 ` Duncan
2012-05-09 18:06   ` Atila

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=20120510201530.GS8938@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=Martin@lichtvoll.de \
    --cc=hka@qbs.com.pl \
    --cc=kaspar@schleiser.de \
    --cc=linux-btrfs@vger.kernel.org \
    /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).