On Tue, Nov 14, 2006 at 02:21:09PM +0300, Al Boldi wrote: > > etc. When I pointed out the system call overhead that would result > > since instead of an open, read, close to read /etc/inetd.conf, you > > would now need perhaps a hundred or more system calls do the > > opendir/readir loop, and then individually opening, reading, and > > closing each file, Hans had a solution ---- > > I have a different solution. > > Plugins into the VFS that handle special situations. > > I could do something like this manually in userland via loop/FUSE, but a more > integrated solution could prove more useful. So now an application that needs to read/write 16 byte files efficiently needs to write a kernel module that gets logged into the VFS?!? And we have to trust our system stability to an application writer to not introduce any bugs into the VFS plugin that might cause a system panic? What's the advantage of using smallish ~16 byte files in this case? If it's ease of application programming, that just got flushed down the drain; writing kernel modules is harder, because (a) the compile/edit/debug cycle, if you screw up, crashes your system, and (b) it requires root privs to install the application. What exactly is the problem that people are trying to solve with trying to get the kernel involved with storing tiny individual datums, as opposed to simply asking the application to store all of these objects in a userland database, where the object layout can be optimized for the application's needs? This really feels like a fragile technological hack looking for a problem to solve.... - Ted - 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
