mount r/w and r/o

[Jérôme Petazzoni]

>Thanks for the reply.  Very interesting.  Could you explain how the bsd box read the raw device and built the internal lookup table?
>  
>
I suppose the BSD box was just accessing the device "raw" (like in 
"/dev/sdX" ; I don't know the exact syntax for BSD, tho), bypassing even 
the partition scheme.

I also guess that the big files created thru the Solaris box were a 
succession of 512-bytes records, each with 4 bytes for the file number, 
then 4 bytes of sector number, the rest being some magic padding. The 
BSD box just had to scan all the sectors and build a kind of hash map.

Sorry for the lack of details and accurracy, but this was more the kind 
of "around a beer" discussion rather than a formal report ... And this 
was, as I understood, a long-term solution, which required a bit of 
hacking before being ready to production (modifying the code of the 
streaming video server running on the BSD boxen, I assume).

>The main reason I wrote "not GFS" is because I'm aware of it and that it would take a bit of work to implement.  I'm currently looking for a quick fix to give me some time to implement a more robust solution.  Also, realizing I had some definite issues w/ my current config, I researched GFS a little while back.  It's my understanding that total storage in a GFS cluster cannot exceed 8TB and we have > 12TB.  I didn't investigate too much further for a work-around. 
>
>Andreas suggested lustre which on the surface appears to be viable.  
>  
>
Let us know your findings ;-)