From: dexen deVries <dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: RAID and file system encryption
Date: Tue, 2 Aug 2011 10:45:45 +0200 [thread overview]
Message-ID: <201108021045.45239.dexen.devries@gmail.com> (raw)
In-Reply-To: <889e085c06295b2f79289eb86be534ef.squirrel-aEpbUQpJQqXlKS8GlytQkw@public.gmane.org>
On Tuesday 02 of August 2011 10:22:24 you wrote:
> Hi,
>
> Just want to find out if nilfs2 supports RAID and native file system
> encryption. Any plans to, if it does not?
not by itself, but it stacks nicely over LVM2 and LUKS for, respectively, RAID
and encryption. Guess that's more unix-ish than having one program (here:
nilfs2 driver) have every possible feature built-in.
> Also, at this stage in its development, are there any serious drawbacks to
> using nilfs2 on a desktop distribution?
there are small ones. There is no KDE GUI for browsing snapshots (as of yet).
Free space does not increase immediately after removing files, which may
surprise users that aren't aware of the snapshotting.
Last but not least, the filesystem plays badly with Bitcoin (and perhaps other
similar programs). Bitcoin causes very many checkpoints to be created, quickly
eating up the free space. AFAIK, it's because bitcoin issues numberous small
transactions to the underlying BDB very often, even 2...4/second in some
cases. And bitcoin's BDB is configured to use 64kb `page' size, IIRC. I've got
sick of it and moved entire bitcoin database to XFS, leaving only wallet.dat
on NILFS2.
On the other hand, NILFS2 works well under mild-loaded MySQL, both on test www
server and for KDE's internal data like Nepomuk and Akonadi storage. I keep 30
days worth of checkpoints on the test server, has already helped us once to
recover certain old files. On PCs and workstations I keep about 10...48h worth
of checkpoints.
NILFS2 performs nicely under mixed workload, both in home and workplace use.
Worth noting is that checkout of large GIT repository (kernel sources) takes
exceptionally short.
Regards,
--
dexen deVries
[[[↓][→]]]
For example, if the first thing in the file is:
<?kzy irefvba="1.0" rapbqvat="ebg13"?>
an XML parser will recognize that the document is stored in the traditional
ROT13 encoding.
(( Joe English, http://www.flightlab.com/~joe/sgml/faq-not.txt ))
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2011-08-02 8:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-02 8:22 RAID and file system encryption LinuxBSDos.com
[not found] ` <889e085c06295b2f79289eb86be534ef.squirrel-aEpbUQpJQqXlKS8GlytQkw@public.gmane.org>
2011-08-02 8:45 ` dexen deVries [this message]
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=201108021045.45239.dexen.devries@gmail.com \
--to=dexen.devries-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.