Hi Jiří. On Fri, Mar 13, 2015 at 06:42:33PM +0100, Jiří Zárevúcky <[email protected]> wrote: > At the moment, I would suggest that we (re)open a discussion about what > each of us expects from the future file system services and libraries, and > figure out steps to get there. I am thinking Michal Koutny who is currently > working on service manager might provide some valuable input with respect > to file system and block device management. From my (current) point of view, main responsibility of VFS is brokering connections from client to appropriate FS servers. I expect that VFS would communicate with the service manager via general interface for brokers. Effectively, it would mean that service manager would be aware of the state of mount units (terminology I borrowed from systemd) whose (un)mount operation was triggered manualy (and not by service manager). Changes in current VFS will be minimal and could be IMO realized in any future version of VFS too.
In the described model, block devices are plain servers that are brokered via Location Service, i.e. current state. Then there are some ideas that would allow early startup process to be more streamlined and would lead to more convenient environment. Some of them are in this ticket [2]. What I think may be benefitial is some sort of filesystem that won't need an underlying block device. That could reduce number of tasks necessary to be launched directly by the kernel in the initial phase (locsrv and initrd), thus needing less tasks to operate in the restricted initial environment (e.g. currently FS servers cannot use logger). It's rather a brainstorm idea as I don't know whether it would be better to have something like tmpfs crossbred with initrd or employ a caching mechanism directly inside VFS. Summarized -- current VFS implementation is conceptually sufficient (regarding service management), later it would be nice to have "less dependent" in-memory filesystem and finer control over placing mounted filesystem into VFS namespace (chroot, pivot mount). Michal [1] http://trac.helenos.org/ticket/525#comment:7 [2] http://trac.helenos.org/ticket/447 _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
