doug,
i appreciate the answer, but it raises a question.
you say "there shouldn't be a buffer cache to deal with",
but one of the whole points on Linux is that all device
i/o is buffer cache mediated (see Linus's famous comments on
demented monkeys). even raw(8) mentions that it circumvents
the kernel block buffer cache.
this whole debacle is one of the reasons i comfortably
ignored Linux for so many years. however, here we are.
i have to use linux and i need to do this repugnant thing
but it looks like O_DIRECT is my answer.
thanks
On Jul 17, 2012, at 8:51 AM, Doug Hughes wrote:
> If you don't have a filesystem there shouldn't be a buffer cache to deal
> with, but you could always open("/dev/sdaf", O_DIRECT);
>
> You'll be responsible for your own seeking and stuff to get to the right
> place.
>
> (also see deprecated man 8 raw)
>
> On 7/17/2012 11:28 AM, Andrew Hume wrote:
>>
>> 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.
>>
>> thanks in advance.
>> andrew
>>
>> ------------------
>> Andrew Hume (best -> Telework) +1 623-551-2845
>> [email protected] (Work) +1 973-236-2014
>> AT&T Labs - Research; member of USENIX and LOPSA
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/
------------------
Andrew Hume (best -> Telework) +1 623-551-2845
[email protected] (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA
_______________________________________________
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/
