Re: [PATCH 49/50] mars: generic pre-patch for mars

["Thomas Schöbel-Theuer" <tst@1und1.de>]

>> Please take into account that MARS Light is not just a "device driver",
>> but a long-distance distributed system dealing with huge masses of state
>> information.
> Which doesn't matter.  No kernel driver has a business messing with the
> filesystem namespace.  Especially no maintaining magic symlink farms.
>

I see the following alternative solutions for this:

a) MARS Light cannot go upstream because it is viewed as a driver
violating the rules. In this case, I could retry submission some years
laters when (subsets of) MARS Full strictly obey some hierarchy rules
which I have to know completely in advance in order to no longer make
any mistakes. However, I am not sure whether the limits in the solution
space are really appropriate for the problem space; I would have to make
new prototype implementations and compare them to other solutions. Only
after that, I would be able to decide whether to go upstream at all, or
to continue an out-of-tree project.

or

b) you permit me exceptions from the rules, justified by the fact that a
_distributed_ "driver" for long-distance replication of terabytes of
data (constructed for long-distance replication of _whole_ _datacenters_
) needs dynamically growing storage space for bulk data. In order to not
re-invent the wheel, you permit me storing both data and metadata in a
reserved filesystem instance. Storing metadata _together_ with the
_corresponding_ (!) bulk data is justified by the fact that separate
storage spaces would need some additional means for ensuring
_consistency_ between them in case of node failures etc.

or

c) MARS Light is viewed as a distributed system, similar to a cluster
filesystem, which just happens to export a block device to userspace (at
current stage of development; notice that the generic brick framework is
not limited to the block device layer).

or

d) both MARS Light and the future Full is viewed as a new generic
framework. In current stage, only some parts dealing with block devices
are implemented. In later stages of MARS Full, the future hierarchy
rules will be automatically checked / established by some future
strategy bricks, according to IOP design principles as proposed in my
papers / in my monography (a detailed discussion is probably out of
scope of this discussion).

Possibly there are further alternatives.

At least in cases c) and d), the sourcecode should IMHO not go to
drivers/block/ but somewhere else (please give me some suggestions; this
is why ./rework-mars-for-upstream.pl has is easily configurable).

Cheers,

Thomas