public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Nathan Roberts <nroberts@yahoo-inc.com>
To: linux-ext4@vger.kernel.org
Subject: Storing inodes in a separate block device?
Date: Thu, 22 May 2008 09:53:59 -0500	[thread overview]
Message-ID: <48358907.3010103@yahoo-inc.com> (raw)


Has a feature ever been considered (or already exist) for storing inodes 
in a block device separate from the data? Is it even a "reasonable" 
thing to do or are there major pitfalls that one would run into?

The rationale behind this question comes from use cases where a file 
system is storing very large numbers of files. Reading files in these 
file systems will essentially incur at least two seeks: one for the 
inode, one for the data blocks. If the seek to the inode were more 
efficient, dramatic performance gains could be achieved for such use cases.

Fast seeking devices (such as flash based devices) are becoming much 
more mainstream these days and would seem like a reasonable device for 
the inodes. The $/GB is not as good as disks but it's much better than 
DRAM. For many use cases, the number of these "fast access" inodes that 
would need to be cached in RAM is near 0. So, RAM savings are also a 
potential benefit.

I've ran some basic tests using ext4 on a SATA array plus a USB thumb 
drive for the inodes. Even with the slowness of a thumb drive, I was 
able to see encouraging results ( >50% read throughput improvement for a 
mixture of 4K-8K files).

I'm interested in hearing thoughts/potential pitfalls/etc.

Nathan





             reply	other threads:[~2008-05-22 15:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-22 14:53 Nathan Roberts [this message]
2008-05-22 15:21 ` Storing inodes in a separate block device? Eric Sandeen
2008-05-22 16:58   ` Nathan Roberts
2008-05-22 16:03 ` Andreas Dilger

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=48358907.3010103@yahoo-inc.com \
    --to=nroberts@yahoo-inc.com \
    --cc=linux-ext4@vger.kernel.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