Re: [lc-devel] filesystem corruption

[Bob A. <cu...@pb...>]

ofcourse i can wait, no hurry. 
i didn't used SMP neither preempt .

with squashfs - as filesystem is compressed compressing cache while reading 
from it is pointless :) so all reads from squashfs which are cached can be
not compressed , and to gain performance uncompressed copy could be hold in 
'most busy inodes' cache (like in my previous idea of having two caches 
with compressed and uncompressed copies) 
right now i am sure wheter squashfs doesn't hold data in uncompressed form in 
caches. i simply don't know. 

second 'feature' could be 'journal' feature allowing writes to squashfs. 
this is a bit tricky - all data written this way would be held on separate
'journal' filesystem. it's offtopic from comp cache - but as you look @ it 
closer it would be just an filesystem with 'dumped' compressed pages on it.
it'll not allow 'real' writes to filesystem, but will make squashfs writable,
which is usefull when you want to make some changes on it (and i assume
compressed data are stored on r/o device like flashdisk) .


On Tuesday 27 May 2003 01:44, Rodrigo Souza de Castro wrote:
> Hey Bob,
>
> On Mon, May 26, 2003 at 11:49:44PM +0200, Bob Arctor wrote:
> > the problem persists even when i use regular swap partition.  orphan
> > inodes and not cleared inodes. not very fatal as with loopback dev,
> > but still quite serious.
>
> The patch I sent you is still unstable. I am hitting some bugs that I
> am trying to fix in my free time (which isn't as much as I'd really
> like). I guess that you should wait for a more stable patch or try the
> 0.24pre5 patch without preempt (and SMP).
>
> BTW, were you using a SMP system when the fs corruption happened?
>
> > btw. i played with squashfs a bit, it might be interesting to join
> > those two patches a bit . squashfs is r/o , i guess merge would be
> > just to use these patches at once :)
>
> Cool, I didn't know this file system. Indeed it would be nice to make
> them working together. We could possibly save compressions, depending
> on the compression algorithms they use, and when they compress the
> data. I guess we should study this fs, thanks for the tip :-)
>
> Regards,

-- 
--