You may want to point out to your security team that being able to share a drive, but not having enough connectivity to run a cluster filesystem is security theater, the damage you can do through a shared drive is far more, and far harder to trace than anything you can do over the network.

In any case, take a look at the code for GFS, it does what you are trying to do, but since it's in the kernel, it may be bypassing some layers that you will have trouble bypassing with a completely userspace solution.

David Lang


On Wed, 18 Jul 2012, Andrew Hume wrote:

point taken.
due to $WORK constraints, the available cluster filesystems can't work
due to firewalls etc.

On Jul 18, 2012, at 3:52 AM, Edward Ned Harvey wrote:

From: [email protected] [mailto:[email protected]]
On Behalf Of Andrew Hume

i have two linux servers each of which has the same piece of SAN
attache dto it as a LUN. that is, svra:/dev/sdbd is the same volume
(or more exactly WWN) as svrb:/dev/sdaf.

what i want to do is write something on svra to /dev/sdbd
and then be able to read it on svrb from /dev/sdaf.
in principle this should work, but on Linux the buffer
cache always inserts doubt. how do i reliably probe
/dev/sdaf for new content? there is no filesystem involved;
i am just talking about raw disk blocks.

I see other people have already answered this, regarding no filesystem.  But
you might also consider using a clustered filesystem.  The whole point of
such a thing is to do precisely this...  With a filesystem.  I believe the
"standard" option built-into most linuxes nowadays would be gfs.  (Not to be
confused with google GFS.)
_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
 http://lopsa.org/
_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to