From: dexen deVries <dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Split some metadata onto separate device?
Date: Fri, 3 Jun 2011 19:42:28 +0200 [thread overview]
Message-ID: <201106031942.29133.dexen.devries@gmail.com> (raw)
In-Reply-To: <20110604.022621.01482278.ryusuke-sG5X7nlA6pw@public.gmane.org>
Hi Ryusuke,
On Friday 03 June 2011 19:26:21 you wrote:
> (...)
> NILFS2 is a log-structured filesystem and that means the filesystem
> itself is a big journal. My understanding is using separate journal
> device has no merit of performance.
>
> On the other hand, We may be able to speed up the filesystem by
> putting DAT (disk address translation) metadata to a separate device.
> I mean putting a full copy of the DAT metadata on the sperate device
> instead of journal of it.
*nods* sounds interesting. Of course changing on-disk format would hurt ;-)
> But, I think we have other approaches to think about before that with
> regard to performance improvement. For example, applying "extent" to
> DAT seems much more effective.
Currently every block of file gets own entry in DAT, right?
By the way, it seems to me that the in-kernel GC does not attempt to de-
fragment files. Is that the case? If so, would probably mean extents would not
help very much for fragmented files. Also, on magnetic media, a lot of seeking
happens in case of fragmented files.
Regards,
--
dexen deVries
``One can't proceed from the informal to the formal by formal means.''
--
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
next prev parent reply other threads:[~2011-06-03 17:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-03 10:29 Split some metadata onto separate device? dexen deVries
[not found] ` <201106031229.38758.dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-06-03 17:26 ` Ryusuke Konishi
[not found] ` <20110604.022621.01482278.ryusuke-sG5X7nlA6pw@public.gmane.org>
2011-06-03 17:42 ` dexen deVries [this message]
[not found] ` <201106031942.29133.dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-06-08 12:48 ` Ryusuke Konishi
[not found] ` <20110608.214852.237935973.ryusuke-sG5X7nlA6pw@public.gmane.org>
2011-06-08 12:58 ` Ryusuke Konishi
[not found] ` <20110608.215803.224753719.ryusuke-sG5X7nlA6pw@public.gmane.org>
2011-06-08 13:08 ` dexen deVries
[not found] ` <201106081508.39345.dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-06-08 13:49 ` Ryusuke Konishi
[not found] ` <20110608.224906.85409768.ryusuke-sG5X7nlA6pw@public.gmane.org>
2011-06-14 11:18 ` Reinoud Zandijk
[not found] ` <20110614111852.GA1263-bVHBekiX4bNgoMqBc1r0ESegHCQxtGRMHZ5vskTnxNA@public.gmane.org>
2011-06-14 13:18 ` Ryusuke Konishi
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=201106031942.29133.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox