[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: mount r/w and r/o

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 ;-)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]