linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vyacheslav Dubeyko <slava@dubeyko.com>
To: Dan Luedtke <mail@danrl.de>
Cc: linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk,
	akpm@linux-foundation.org, chaosman@ontika.net, muthur@gmail.com,
	kerolasa@iki.fi, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fs: Introducing Lanyard Filesystem
Date: Tue, 21 Aug 2012 10:09:42 +0400	[thread overview]
Message-ID: <1345529382.2457.39.camel@slavad-ubuntu-11> (raw)
In-Reply-To: <1345333117-2826-1-git-send-email-mail@danrl.de>

Hi,

On Sun, 2012-08-19 at 01:38 +0200, Dan Luedtke wrote:
> This patch introduces the Lanyard Filesystem (LanyFS), a filesystem
> for highly mobile and removable storage devices.
> 

Did you have any performance comparison of your file system with others?
Have you any benchmark results? I think that simplicity can be a
valuable thing but performance is a key factor, especially for business
guys.

I think that maybe compression or/and encryption support can be a
valuable feature for such niche of file system that you declared.
Efficient compression support is very important feature for embedded
solutions. Moreover, using of hardware opportunity in the field of
compression or encryption can keep driver code simple.

By the way, what about fault-tolerance of your file system? I don't dive
deeply in documentation of your file systems. But, I think that for USB
sticks or removable storages it is very common situation of sudden
switch off. So, it is very important for your file system to be a very
tolerant to such use-cases. How can you estimate tolerance of your file
system architecture for failure as normal situation?

Moreover, I think that simplicity and strong tolerance to file system
corruption can be a feature. I mean that if you have simple on-disk
layout then, maybe, it is possible to try working in very corrupted
environment also. For the end user, from my point of view, possibility
to work in the case of file system corruption can be very precious
feature.

I think that also for your file system such feature as easy
recoverability of user information in the case of complete corruption of
file system can be very useful thing for an end user. Such easy
recoverability can be achieved by means of on-disk layout and file
system driver's techniques, I think. So, simplicity and easy
recoverability of user data can be a valuable feature also.

With the best regards,
Vyacheslav Dubeyko.


  parent reply	other threads:[~2012-08-21  6:09 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-18 23:38 [PATCH] fs: Introducing Lanyard Filesystem Dan Luedtke
2012-08-18 22:06 ` Alan Cox
2012-08-18 22:16 ` richard -rw- weinberger
     [not found]   ` <c925f795-28d8-4e6d-8131-9a14d6e83659@email.android.com>
2012-08-18 22:27     ` richard -rw- weinberger
2012-08-19 10:12   ` Dan Luedtke
2012-08-19 10:14     ` Marco Stornelli
2012-08-19 13:34       ` Dan Luedtke
2012-08-19 12:02         ` Jochen Striepe
2012-08-19 15:33           ` Dan Luedtke
2012-08-19 14:07             ` Jochen Striepe
2012-08-19 14:27             ` Al Viro
2012-08-19 16:53               ` Dan Luedtke
2012-08-19 15:12                 ` Al Viro
2012-08-19 15:24                 ` Marco Stornelli
2012-08-20 17:36                   ` Dan Luedtke
2012-08-19 21:04             ` Theodore Ts'o
2012-08-19 21:20               ` Andi Kleen
2012-08-19 23:06               ` Carlos Alberto Lopez Perez
2012-08-20  0:47                 ` Theodore Ts'o
2012-08-20  6:07                   ` Raymond Jennings
2012-08-20  6:49                     ` Oliver Neukum
2012-08-20  9:12                   ` Alexander Thomas
2012-08-20 13:21                     ` Theodore Ts'o
2012-08-22  8:38                       ` Arnd Bergmann
2012-08-20 11:36                   ` Pavel Machek
2012-08-20 12:49                     ` Ronnie Collinson
2012-08-20 17:48               ` Dan Luedtke
2012-08-19 13:25         ` Marco Stornelli
2012-08-19 15:45           ` Dan Luedtke
2012-08-22  9:53         ` Jan Engelhardt
2012-08-21  6:09 ` Vyacheslav Dubeyko [this message]
2012-08-23 17:29 ` Eric W. Biederman
2012-08-24 11:50 ` Prashant Shah

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=1345529382.2457.39.camel@slavad-ubuntu-11 \
    --to=slava@dubeyko.com \
    --cc=akpm@linux-foundation.org \
    --cc=chaosman@ontika.net \
    --cc=kerolasa@iki.fi \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mail@danrl.de \
    --cc=muthur@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /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).