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

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]

Date:	Wed, 02 Jul 2014 18:20:20 +0200
From:	Thomas Schöbel-Theuer <tst@...d1.de>
To:	Christoph Hellwig <hch@...radead.org>
CC:	Greg KH <gregkh@...uxfoundation.org>,
	Thomas Schoebel-Theuer <tst@...oebel-theuer.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 49/50] mars: generic pre-patch for mars

> Most likely you shouldn't do either. A block driver really should not
> be removing directories from the filesystem namespace. 

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.

The /mars/ filesystem (which is a reserved directory) is a means for
storage of transaction logfiles. This has one big advantage: it is a
_shared_ storage space for _multiple_ resources.

The current setup at 1&1 datacenters is dealing with at least 7
resources in parallel; the number is likely to grow in future.

IMHO, replacing the /mars/ filesystem by block device storage would
likely mean to have a rather static ring-buffer like structure for
_each_ of multiple resources.

When taking your argument (which I can understand) to the extreme, I
would not even be allowed to use files as a dynamic storage for
transaction logfiles at all.

In essence, I fear that such a requirement  would mean to re-implement
the core functionality of a classical filesystem, namely (a) creating
multiple instances of _dynamic_ storage (aka files) out of a single
static storage (aka block device), and (b) synchronizing parallel access
to that. My idea was to re-use that functionality already implemented by
filesystems, where fundamental problems such as fragmentation are
already solved.

There is a second reason for using a filesystem:

As explained in slide 10 of the LinuxTag presentation, the symlink tree
residing in /mars/ is also used for storage and propagation of metadata
information.

Unfortunately, the slides don't contain my oral explanations (both at
LCA2014 and LinuxTag2014) about the symlink tree. It is used for three
purposes at the same time:

1) as a _persistent_ key->value store.

2) as the _only_ means of high-level metadata communication in the
long-distance cluster.

3) as interface between userspace and kernelspace (no longer any binary
interfaces).

IMHO, if I had to avoid filesystem operations at least regarding
symlinks, the complete MARS Light design would have to be redesigend /
re-implemented in a very different way, essentially a completely
different implementation, essentially forcing me to throw away the
effort of years.

Notice that MARS Full is planned to abstract away from concrete storage
formats such as filesystems, so your objective could probably be met in
future (if it will have some advantages).

Please permit me to use /mars/ for MARS Light as a reserved space where
not only transaction logfiles for multiple resources are residing, but
also the symlink tree is allowed to reside.

Cheers,

Thomas

--
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/