JNode System-file Tree Structure

According to the message by Daniel Noll :

 
It would probably be a good idea to avoid the UNIX directory layout. It's full of design decisions 
which no longer make sense in the modern world. 

e.g. separating bin and sbin when you could use the +x flag to distinguish the two types of 
executable, separating bin into  /bin, /usr/bin, etc. to support boot-time repair when live 
CDs are a better solution. About the only principle which still applies is that user data 
should be on a different partition to system files as the system files are more easily created from 
scratch. And that's only when a user actually cares about data integrity, the vast majority of 
users can make do with a single partition these days (not counting swap of course.)

The only Linux distro I know of without this problem is GoboLinux (there is probably at 
least one more.) 

Having the commands similar is fair enough I think, although you'll get a fair number of 
people who say they're used to dir and not ls.

This is the right position of this opinion.

Background bits:
a fundamental design decision is the guideline that "everything" should be a "file", manipulated by a single simple API (open, read, write, close) that allows extension (ioctl)

physical storage, network filesystems, and in-memory "pseudo" filesystems are abstracted together in a single "tree" via mount, rather than using "drive letters" (using a vnode tree in Solaris, for example).

In a traditional inode-based filesystem, all files in a physical filesystem are directly accessible by their inode number.

a "directory" is a metadata file that contains name-inode pairs (conceptually) rooted at directory '/' (pointed at by the mountpoint inode)

code and data are simply datablocks referenced through inode maps, treated differently based on permission bits in the inode.

So, that's a basis what I know for filesystems. If you want the detailed version, see Solaris Internals by Jim Mauro and Richard McDougall, page 470 (hehe) and chapters 11-15

So, the 'abstract container interface' sounds to me exactly like the Solaris virtual filesystem nodes (vnodes). Traditionally, the mountpoint inode of the disk filesystem that holds "root/boot" is mounted as the root of the tree, but there's no reason you have to do that. During jumpstart, the kernel mounts an NFS path (one example) to the in-core root vnode.

=== Ondisk filesystem ===
Since I hate defragging, let me make my plea for EXT2 or ZFS to be the default on-disk filesystem, with JFAT as a selectable option, rather than default. Also, there's no patent question involved, which FAT still has hanging over it.

=== Tree Layout ===
A tree is simply a namespace.
Java already implements a namespace layout in its design and operation, in the form of the classloader's package layout/loading scheme. Why not base your initial tree design around that?

So, why not just anchor the package paths at / for classloader?

When a user/permission scheme for multi-user use comes into play, it could still protect those from accidental user error.

--- System/Plugins ---
org.jnode.etc ... why not just use their package paths as-is?
Package org.jnode.etc becomes /org/jnode/etc/
com.exileinparadise.insanity becomes /com/exileinparadise/insanity.

Extensions by the local user(s) and incorporation of add-ons becomes a no-brainer. Tie in a subversion client and you have a ready made layout for network updates too.

--- Container root /jnode ---
As far as the namespace structure goes, is there any technical reason that /jnode/ has to prefix every path in the tree, or is it simply everyone's preference?

--- Namespace Personalities ---
Why not allow each user to have their own file namespace?
A flexible filetree/namespace layout scheme might make it easier for customized distributions later too, for people who like the Unix, Linux, Mac, Windows, or other layout.

Jnode could ship with a "default" filetree configuration, but have that be controlled or built from a properties file that the system owner can customize.

The namespace/filetree mapper reads a configuration that maps Jnode objects like classes, Java sources, Javadocs, plugins, metadata, pseudo-filesystems and more to some set of tree paths specified by the system builder/owner.

A user could then have their own custom file to override that.
If I am a Linux user on a system that the owner setup to look like Windows, then I could simply shuffle the view of the standard system objects around to suit me.

Fundamentally, this is just an extension of the existing vfstab/fstab concept which says where to make disk device content into the in-memory tree. Extend that to cover all Jnode objects, not just disk content of specific filesystems?

A namespace/filetree is simply a "renderer" that reads a set of data structures and presents a view of them, so why fix that in stone?

Jnode boots into core memory and can run exclusively from there, now.
A disk is not even required, and that is a powerful thing to leverage fully.

However, if we are simply talking about nailing down the default tree, my thoughts are something like:

/{com,org,net,us,in,...} DNS domains/ISO3166 country codes/package classloader paths, mapped as is with slashes instead of the dots, the way Java intended. Store the sources here too. What better way to learn the system?

/org/jnode/ - the jnode.gz and initjars go here, for build.sh too
It's the base for Jnode's package path anyway, just build into it, and let GRUB load straight from it.

/boot - a GRUB favorite

/jifs - Jnodes pseudofs needs a home, right? devices/ belongs here too, not as /devices, IMO

/
If the system will host multiple users, then /home, or whatever.

Okay, so much for thinking out loud.
Feel free to flame or trash this rambling as you see fit.

--
Robert "Exile In Paradise" Murphey

hai,
We should keep this simplest Form of the SystemFileSystem proposed by Ewout for this primary stage.Because this matter will always create conflictions between all to make a Exact decision, as the viewpoint of the all Users+developers are always different.
So, it will be better primarily keeping it.And if possible to give freedom the users for making their SystemFileSytem as they want.
Thanks tango

I propose the following:

/jnode The root of the container
/jnode/system/kernel Contains kernel and the initial jars
/jnode/system/plugins Contains the plugins
/jnode/system/boot Contains the bootloader files
/jnode/system/config Contains the configuration data
/jnode/user All user installed stuff
(/jnode/user/programs)
(/jnode/user/home)
(/jnode/user/home/me)

I think this way, if you hide som folders from view, the filethree becomes less scary. Example: /bin /usr/bin /usr/local/bin. For a programmer folders are easy. I have been teaching for some years, and the absolut nightmare for beginners are lots of folders.
A consistent and clean file system in the beginning is an relatively easy task to acomplish and gives much value for the work. If some folders are going to be scary hide them behind a nice named one. Folders is also great for explaining what they contain. You say to the users: Do not touch anything in /jnode/system (C:\winnt C:\windows).
If something scary happens in system, the end user never sees any new folders or anything different. Some examples:

ls /jnode

system
users

tar cvfz programs.tgz /jnode/user/programs
tar cvfz everything_installed_so_fartgz /jnode/user
tar cvfz system_backup_02.06.2005.tgz /jnode/system

If there is going to be stored som good old config files, xml seems to me the most consisten choice, I hate linux's 10-100 differtent config scripts. It's working, but you get so dead tierd of everything you have to learn. Think of a linux with a standard dtd for every system xml file! And how easy this makes creating a gui for configurating the system becomes. Not only system configuration, but also programs, logfiles etc. One program to edit and view the entire system and all program's config files.

Hi,

is someone working on that topic ? (Or is the desicion not yet made?)

Trickkiste

What about a db based filesystem like the new filesystem in longhorn?
You can have "views" like an audio view.
In the audio view you can select "sort by year" and in the audio view you see directories like 1970 and 1980 which contains audio files from that year. If you select "sort by genre" you see directories like "pop music" and "clasic music".

is this kewl ?

To avoid a lot of different types of formats when we are to configurate the system it would be a very good idea to have a common jnode standard for config files. Any good ideas?

Regards,
Martin

Hi,
wouldn't it be possible to isolate some dirs of the OS, to mount them in ReadOnly ? For ex. in Read-Only all the /boot , and all of the system, but WITHOUT the variant part (config, logs, etc) in Read-Write ... like /var in Linux
Having the ability for the System Admin (via a User Role), or the JNode Installer to change the mount mode as it will be necessary.

For all the (Non-OS Packages) we could use a similar approach (another partition):
/prg for the read-only part, and (/var ? )/prg.config for the variant parts.
Then, the read/write here could be handled by the JNode Installer and the JNode Security Manager.

For this the best could be having (in the future) the LVM Like that in Linux, to allocate logical partitions as they are needed.

Comments ?

Bye,
Sandro

If I understand well, System files can be installed on :
- its own new partition (harddrive, removable media, ...)
- an existing partition (single file based container)
- a ROM (maybe it can replace the BIOS)
- an USB key (cool, but need a compatible BIOS)
- a network loader (a 'network computer' without harddrive I think)
- other things I don't think about ...

For network loader, maybe JNode can be loaded from some radio technology (WiFi). I don't know if it's possible to do it nowadays (booting from WiFi).