Re: Some very basic questions

[jim owens <jowens@hp.com>]

Hearing what user's think they want is always good, but...

Stephan von Krawczynski wrote:
> 
> thanks for your feedback. Understand "minimum requirement" as "minimum
> requirement to drop the current installation and migrate the data to a
> new fs platform".

I would sure like to know what existing platform and filesystem
you have that you think has all 10 of your features.

> Of course you are right, dealing with multiple/parallel mounts can be quite a
> nasty job if the fs was not originally planned with this feature in mind.
> On the other hand I cannot really imagine how to deal with TBs of data in the
> future without such a feature.
> If you look at the big picture the things I mentioned allow you to have
> redundant front-ends for the fileservice doing the same or completely
> different applications. You can use one mount (host) for tape backup purposes
> only without heavy loss in standard file service. You can even mount for
> filesystem check purposes, a box that does nothing else but check the
> structure and keep you informed what is really going on with your data - and
> your data is still in production in the meantime.
> Whatever happens you have a real chance of keeping your file service up, even
> if parts of your fs go nuts because some underlying hd got partially damaged.
> Keeping it up and running is the most important part, performance is only
> second on the list.
> If you take a close look there are not really 10 different items on my list,
> depending on the level of abstraction you prefer, nevertheless:
> 
> 1) parallel mounts

What I see from that explanation is you have a "system design" idea
using parallel machines to fix problems you have had in the past.
To implement your design, you need a filesystem to fit it.  I think
it is better to just design a filesystem without the problems and
configure the hardware to handle the necessary load.

> 2) mounting must not delay the system startup significantly
> 3) errors in parts of the fs are no reason for a fs to go offline as a whole
> 4) power loss at any time must not corrupt the fs
> 5) fsck on a mounted fs, interactively, not part of the mount (all fsck
> features)

I think all of these are part of the "reliability" goal for btrfs
and when you say "fsck" it is probably misleading if I understand
your real requirement to be the same as my customers:

   - *NO* fsck
   - filesystem design "prevents problems we have had before"
   - filesystem autodetects, isolates, and (possibly) repairs errors
   - online "scan, check, repair filesystem" tool initiated by admin
   - Reliability so high that they never run that check-and-fix tool

Note that I personally have never seen a first release meet
the "no problems, no need to fix" criteria that would obviate
any need for a check/fix tool.

jim