From: Hans B. <han...@gm...> - 2011-12-20 16:06:36
|
Hi. I really do not know how to start this, but I have encountered a problem that has bugged me forever. I have turned my file system inside out for bugs but I can not find anything really that indicates a problem in my code. I will try to explain the problem. Hopefully it will make sense. My file system handles compressed streams of data. This means that in some specific situations (depending on what tool is used) when an offset is requested far outside current stream position I am forced to return some dummy data, still according to the size as specified in the request. In this case I just return a buffer filled with 0xff. If I at the same time just do 'cat' on the file problem starts :( 'cat' is just reading the file sequentially, so there is no need to fake data in this case. However, if I first run 'cat' on the file and while it is working, start another tool that will access the same file but forces my file system to return the dummy buffer, the contents of the 'cat' redirect output is corrupted! The very same dummy 0xff buffer can be found by doing hexdump on the output! What I can see tell by adding traces in my code is that the read offset from where the dummy buffer was returned is never entering my file system for the 'cat':ed file! Hence, my guess is that is was picked up from a cache "somewhere". I do not set fi->keep_cache, actually I force it to 0 at each open request but that still does not seem to help. Also, I can not for my life understand why doing it in the opposite order works!? If I first start the tool that forces me to return a dummy buffer, and after that buffer has been returned do the 'cat' operation, it works!?? Is there some way in which I can force a flush of the file system cache for each open of a file to force it to enter my callbacks at all times? The keep_cache=0 does not seem to help, also from what I understand the value of 0 in this case is the default. If I set it to 1 problem gets even worse. I was thinking about the O_SYNC flag in open, but is that really an option here? I can not tell the user of the file system how to open a file using standard tools like 'cat' :( Any ideas what I could try next? Hans |
From: Goswin v. B. <gos...@we...> - 2011-12-21 14:20:45
|
Hans Beckérus <han...@gm...> writes: > Hi. I really do not know how to start this, but I have encountered a > problem that has bugged me forever. > I have turned my file system inside out for bugs but I can not find > anything really that indicates a problem in my code. > I will try to explain the problem. Hopefully it will make sense. > > My file system handles compressed streams of data. This means that in > some specific situations (depending on what tool is used) when an > offset is requested > far outside current stream position I am forced to return some dummy > data, still according to the size as specified in the request. In this > case I just return a buffer filled with 0xff. > If I at the same time just do 'cat' on the file problem starts :( > 'cat' is just reading the file sequentially, so there is no need to > fake data in this case. > However, if I first run 'cat' on the file and while it is working, > start another tool that will access the same file but forces my file > system to return the dummy buffer, the contents of the 'cat' redirect > output is corrupted! The very same dummy 0xff buffer can be found by > doing hexdump on the output! > What I can see tell by adding traces in my code is that the read > offset from where the dummy buffer was returned is never entering my > file system for the 'cat':ed file! Hence, my guess is that is was > picked up from a cache "somewhere". I do not set fi->keep_cache, > actually I force it to 0 at each open request but that still does not > seem to help. Also, I can not for my life understand why doing it in > the opposite order works!? If I first start the tool that forces me to > return a dummy buffer, and after that buffer has been returned do the > 'cat' operation, it works!?? > > Is there some way in which I can force a flush of the file system > cache for each open of a file to force it to enter my callbacks at all > times? The keep_cache=0 does not seem to help, also from what I > understand the value of 0 in this case is the default. If I set it to > 1 problem gets even worse. > I was thinking about the O_SYNC flag in open, but is that really an > option here? I can not tell the user of the file system how to open a > file using standard tools like 'cat' :( > > Any ideas what I could try next? > > Hans I would say: FIX THE STUPID FILESYSTEM. Returning a dummy buffer is a really bad idea. You are probably hitting something in the kernel that merges read requests for the same data into a single read. Even without any long term caching the sequential and random access can overlap while the data is on the fly. I don't think there is any way to force that every read, even parallel ones, do get passed to the filesystem. MfG Goswin |
From: Hans B. <han...@gm...> - 2011-12-21 15:51:16
|
On Wed, Dec 21, 2011 at 3:19 PM, Goswin von Brederlow <gos...@we...> wrote: > > I don't think there is any way to force that every read, even parallel > ones, do get passed to the filesystem. > > MfG > Goswin And, even better, if there was some way to tell the kernel to not cache a particular read request ;) In this case, when I know I return false information, it would be nice to have a feature to invalidate any cached page information... Hans |
From: Hans B. <han...@gm...> - 2011-12-21 14:25:51
|
To work around the page cache problems I now use fi->direct_io=1 and it seems to resolve most of my problems. But my guess is that using direct I/O might cause new ones :( Also, I assume that using direct_io completely obsoletes any use of keep_cache. Hans On Tue, Dec 20, 2011 at 5:06 PM, Hans Beckérus <han...@gm...> wrote: > Hi. I really do not know how to start this, but I have encountered a > problem that has bugged me forever. > I have turned my file system inside out for bugs but I can not find > anything really that indicates a problem in my code. > I will try to explain the problem. Hopefully it will make sense. > > My file system handles compressed streams of data. This means that in > some specific situations (depending on what tool is used) when an > offset is requested > far outside current stream position I am forced to return some dummy > data, still according to the size as specified in the request. In this > case I just return a buffer filled with 0xff. > If I at the same time just do 'cat' on the file problem starts :( > 'cat' is just reading the file sequentially, so there is no need to > fake data in this case. > However, if I first run 'cat' on the file and while it is working, > start another tool that will access the same file but forces my file > system to return the dummy buffer, the contents of the 'cat' redirect > output is corrupted! The very same dummy 0xff buffer can be found by > doing hexdump on the output! > What I can see tell by adding traces in my code is that the read > offset from where the dummy buffer was returned is never entering my > file system for the 'cat':ed file! Hence, my guess is that is was > picked up from a cache "somewhere". I do not set fi->keep_cache, > actually I force it to 0 at each open request but that still does not > seem to help. Also, I can not for my life understand why doing it in > the opposite order works!? If I first start the tool that forces me to > return a dummy buffer, and after that buffer has been returned do the > 'cat' operation, it works!?? > > Is there some way in which I can force a flush of the file system > cache for each open of a file to force it to enter my callbacks at all > times? The keep_cache=0 does not seem to help, also from what I > understand the value of 0 in this case is the default. If I set it to > 1 problem gets even worse. > I was thinking about the O_SYNC flag in open, but is that really an > option here? I can not tell the user of the file system how to open a > file using standard tools like 'cat' :( > > Any ideas what I could try next? > > Hans |