linux-kernel - Re: Mis-Design of Btrfs?

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: <alpine.DEB.2.02.1107150900110.3745@asgard.lang.hm>
Date:	Fri, 15 Jul 2011 09:03:39 -0700 (PDT)
From:	david@...g.hm
To:	NeilBrown <neilb@...e.de>
cc:	Chris Mason <chris.mason@...cle.com>,
	Ric Wheeler <rwheeler@...hat.com>,
	Nico Schottelius <nico-lkml-20110623@...ottelius.org>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	Alasdair G Kergon <agk@...hat.com>
Subject: Re: Mis-Design of Btrfs?

On Fri, 15 Jul 2011, NeilBrown wrote:

> On Thu, 14 Jul 2011 21:58:46 -0700 (PDT) david@...g.hm wrote:
>
>> On Thu, 14 Jul 2011, Chris Mason wrote:
>>
>>> Excerpts from Ric Wheeler's message of 2011-07-14 02:57:54 -0400:
>>>> On 07/14/2011 07:38 AM, NeilBrown wrote:
>>>>> On Thu, 14 Jul 2011 07:02:22 +0100 Ric Wheeler<rwheeler@...hat.com>  wrote:
>>>>>
>>
>> I would suggest that each layer take the value it's give, do an integer
>> division by the number of values that layer supports, using the modulo
>> value for that layer and pass the rest of the result down to the next
>> layer.
>
> I, on the other hand, would suggest that each layer be given the freedom, and
> the responsibility, to do whatever it thinks is most appropriate.
>
> This would probably involved checking the lower levels to see how many
> strategies each has, and doing some appropriate arithmetic depending on how
> it combines those devices.

nothing is wrong with doing something smarter than what I was proposing, I 
was just intending to propose a default rule that would work (just about) 
everywhere. I was specifically trying to counter the throught hat the 
method number would/should be contant as it's passed down the layers.

The proposal had been made to have each layer do the retries for the layer 
below it, that would avoid this stacking problem, but at the cost of 
potentially doing a LOT of retries without the upper level being able to 
limit it.

David Lang

> One problem here is the assumption that the lower levels don't change, and we
> know that not to be the case.
> However this is already a problem.  It is entirely possible that the request
> size parameters of devices can change at any moment, even while a request is
> in-flight ... though we try to avoid that or work around it.
>
> The sort of dependencies that we see forming here would probably just make
> the problem worse.
>
> Not sure what to do about it though.... maybe just hope it isn't a problem.
>
> NeilBrown
>
>
>>
>> this works for just trying values until you get the error that tells you
>> there are no more options.
>>
>>
>> things can get very 'intersesting' if the different options below you have
>> different number of options (say a raid1 across a raid5 and a single disk)
>> but I can't think of any good way to figure this out and assemble a
>> sane order without doing an exaustive search down to find the number of
>> options for each layer (and since this can be different for different
>> blocks, you would have to do this each time you invoked this option)
>>
>> David Lang
>
>
--
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/