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 --]
next prev parent 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).