From: Terje O. <os...@gm...> - 2004-09-22 19:35:51
|
Miklos Szeredi <miklos@...> writes: > > > Alternatively, I can pre-fill the files as soon as stat is called on > > them, and keep the data around in a temporary file until it is either > > forgotten or Open+Read are called. But I don't want to have to generate > > the file data until it is actually going to be read.. > > This has been discussed before doing the direct_io implementation: > > http://sourceforge.net/mailarchive/message.php?msg_id=8648073 > > The second option is something like what you describe, and could still > be implemented. On Tuesday 08 June 2004 02:55, Miklos Szeredi wrote: > > > On Monday 07 June 2004 20.17, Harris, Jeff wrote: > > ... > > > The problem I"m > > > facing is that FUSE (or perhaps Linux) is requiring me to know the > > > file size before calling read. Computing the file size is an > > > expensive operation which I would like not to perform during a > > > getattr call. > > > On Monday 07 June 2004 23:50, Adrian Dagurashibanipal von Bidder wrote: > > Represent the file as a FIFO instead of a regular file? > > Nice idea! If only sequential access is required, than this is the > simplest way. > > Miklos I too am interested in this. Magic hidden files or visible files that can be read from and written to in order to obtain or set configuration or status info in the process serving the filesytem requests. I thought of using FIFO's but they appear to be completely implemented in the kernel and don't involve the filesystem at all other than to check the existence of the FIFO file. Is there somehow a way to cause the kernel to force the fifo read and write calls to be passed through FUSE? |