From: John Richard Moser <nigelenki@comcast.net>
To: Phil Lougher <phil.lougher@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Designing Another File System
Date: Wed, 01 Dec 2004 00:11:44 -0500 [thread overview]
Message-ID: <41AD5290.9060704@comcast.net> (raw)
In-Reply-To: <cce9e37e04113018465091010f@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Phil Lougher wrote:
|
| Yes you're right. What I said was total rubbish. I read your
| statement as meaning to dynamically allocate/deallocate inodes from a
| set configured at filesystem creation...
|
heh :P np
|
|>
|>Ugly, but ok. What happens when i actually have >4G inodes though?
|
|
| Well this is an issue that affects all filesystems on 32-bit systems
| (as Alan said inode numbers are 64 bits on 64 bit systems). To be
| honest I've never let this worry me...
|
| A 32-bit system can never cache 4G inodes in memory without falling
| over, and so a simple solution would be to allocate the 32-bit inode
| number dynamically (e.g. starting at one and going up, keeping track
| of inode numbers still used for use when/if wraparound occured), this
| would guarantee inode number uniqueness for the subset of file inodes
| in memory at any one time, with the drawback that inode numbers
| allocated to files will change over filesystem mounts. Alternatively
| from reading fs/inode.c it appears that inode numbers only need to be
| unique if the fast hashed inode cache lookup functions are used, there
| are other inode cache lookup functions that can be used if inode
| numbers are not unique.
|
*blink*
slower next time.
|
|>| I've had people trying to store 500,000 + files in a Squashfs
|>| directory. Needless to say with the original directory implementation
|>| this didn't work terribly well...
|>|
|>
|>Ouch. Someone told me the directory had to be O(1) lookup . . . .
|
|
| Ideally yes, but ultimately with your filesystem you make the rules
| :-) The Squashfs directory design was fast for the original expected
| directory size (ideally <= 64K, maximum 512K) seen on embedded
| systems. The next release of Squashfs has considerably improved
| indexed directories which are O(1) for large directories. To be
| released sometime soon, if anyone's interested...
|
hm. If I ever get a basic design off the ground (within the next month,
if ever), would you be willing to work with me on putting on polish and
possibly coding it? Preferably I'd like to find some time to learn how
to code an FS myself-- though my goal is to make "the perfet file
system," so I can't imagine what use that'd have ;) (well, I could fail
the second time around-- I sure fucked up my first attempt last year).
Maybe you could give me guidance when I get to that point, if you don't
have time/will to do (what will inevitably become the bulk of) the work?
Of course, you don't HAVE to, and don't have to commit to this now; but
if you want, I'll poke you later about it.
| Phillip Lougher
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBrVKPhDd4aOud5P8RAsO0AJ9LWWR2EItEl7HrcMlt0SZl+PjMEACeMnBQ
Rmhzqz+M8NXQZoYiVoaUbHU=
=6Roh
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2004-12-01 5:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-30 4:32 Designing Another File System John Richard Moser
2004-11-30 7:16 ` Bernd Eckenfels
2004-11-30 13:07 ` Helge Hafting
2004-12-01 1:16 ` John Richard Moser
2004-11-30 16:31 ` Alan Cox
2004-11-30 18:28 ` Valdis.Kletnieks
2004-11-30 17:46 ` Alan Cox
2004-11-30 19:00 ` Jan Engelhardt
2004-11-30 19:14 ` Valdis.Kletnieks
2004-11-30 20:22 ` Valdis.Kletnieks
2004-12-02 23:32 ` David Woodhouse
2004-12-01 1:35 ` John Richard Moser
2004-11-30 19:22 ` Phil Lougher
2004-12-01 1:42 ` John Richard Moser
2004-12-01 2:46 ` Phil Lougher
2004-12-01 4:32 ` Bernd Eckenfels
2004-12-01 7:51 ` Phil Lougher
2004-12-01 5:11 ` John Richard Moser [this message]
2004-12-02 20:18 ` Jan Knutar
2004-12-07 2:01 ` Phil Lougher
2004-12-07 2:31 ` John Richard Moser
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=41AD5290.9060704@comcast.net \
--to=nigelenki@comcast.net \
--cc=linux-kernel@vger.kernel.org \
--cc=phil.lougher@gmail.com \
/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