Theodore Tso wrote: > 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? An API would probably be in order. > 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? Performance due to non-redundancy. > This really feels like a fragile technological hack looking for a > problem to solve.... Or a desire to let people choose what they want. Think freedom... Thanks! -- Al - 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
