Re: [SSI-devel] CVS:OPENSS-RH kernel oops CFS/NFSD interaction

[Roger T. <pe...@ho...>]

>>>If you want to provide specific test cases, I can see if there is 
>>>anything I can do, but chard has to make sure some things get to disk so 
>>>that failover will work properly.
>>>
>>>John
>>>
>>
>>Some example test cases for chard poor performance
>>1. rm -rf linux-ssi
>>2. make dep in the kernel sources directory
>>3. chown user:group * -R where * include directories containing many files 
>>like linux-ssi and the openssi cvs checkouts
>>
>
>CFS stacks over a physical file system and needs certain semantics from the 
>physical filesystem in order to do failover. If we return a file creation 
>or deletion to the an application on a client node and a failover occurs, 
>we need to guarantee that operation is reflected on the disk after 
>fsck/journal-replay.
>
<... snip...>
>We need to look at other journaling filesystems to see if they make 
>stronger guarantees with their journaling. If they do, SSI can achieve 
>performance closer to the base.
>

Mount option sync should make this guarantee.  If we do that and have an 
optional switch in /proc/cluster to turn off the evil stuff for ext3 then 
would it bring us some improvements at least in reduced code path?

>returning the correct size. I am quite puzzled. I need to look at what cpp 
>is actually doing to see how it is getting confused.
>

drbdadm_parser.c doesn't exist prior to make and is generated on demand.  
Anything related to the CFS async read ahead cache feature that could 
possibly have timing issues with this CFS update patch?  The data and size 
is correct on the filesystem as you say, so the remaining issue seems to be 
with mmap.

-Roger