>But your points seem to be valid as long as you can give more details >on "some file systems". ;-) I don't think I can do that. I couldn't even list ALL the filesystem types, much less tell which ones are implemented which way -- in which versions of Linux. I'd embarass myself if I tried. I can barely remember the generalities; I don't find the actual filesystem type inventory to be very interesting myself. If you're willing to build something that doesn't work with Linux filesystems in general, but just works with the "important" ones, then it makes more sense to go the other way -- identify the ones you care about and ask if they fit the assumptions you require. I believe ext3 everywhere it exists today meets your expectations for inodes and device numbers -- if you add some conditions so that the device number - filesystem association is permanent. Again being general, but a little less, I can say that the inode assumption clearly doesn't work on a system that has more than 4G files. I would suspect the various supercomputing cluster filesystems, and I heard a long time ago AFS broke the 32 bit inode number barrier. Filesystems imported from non-Unix places often have trouble synthesizing a Unix inode number. Finding a filesystem without a useful normal device number to identify it is a lot easier. Any filesystem that doesn't live by design on a single disk device: network filesystem, distributed filesystem, multi-volume filesystem, non-storage filesystem (like proc), or unconventional storage filesystem such as ramfs or tmpfs. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
