| 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
| ||
|
Date: Thu, 22 May 2008 09:53:59 -0500 From: Nathan Roberts <nroberts@...oo-inc.com> To: linux-ext4@...r.kernel.org Subject: Storing inodes in a separate block device? 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists