I have patched my server with OpenSSL 1.0.1j for the Poodle vulnerability. Been reading the spec on TLS_FALLBACK_SCSV. From what I can tell in order for TLS fallback prevention to work properly it requires the client to announce it in the client hello, and if not, even if the server supports fallback, it will not be used. What is the expected behavior if only one side, say the server side, only supports it?
That is correct: clients that do not support TLS_FALLBACK_SCSV cannot benefit from the server's implementation. However, understanding the intent of the feature may help put your mind at ease.
There are broadly 2 categories of TLS/SSL implementations: modern and legacy. Modern implementations use recent TLS versions (though they may be locked into older versions like TLS 1.1) and can be updated with support for additional extensions. The code required to add TLS_FALLBACK_SCSV support into a TLS library is vastly smaller and simpler than implementing a new TLS version.
Legacy implementations cannot be updated, but may need to be supported for various practical reasons. TLS_FALLBACK_SCSV allows modern implementations to support legacy protocols without being coerced into using them when both endpoints can support a better protocol.
So communication with a legacy implementation is never protected, presumably because it doesn't support newer TLS versions anyway. Obviously, the safest method would be to disable all but the very latest TLS version, but that would render a large portion of TLS services inaccessible. TLS_FALLBACK_SCSV is a good way (once it is widely-enough adopted) to allow legacy connectivity when necessary, while still preventing modern implementations from being downgraded by a man-in-the-middle who can drop selected packets.
To answer your question directly, the SCSV is sent only by the client. As a pseudo-ciphersuite, it can never be "chosen" by the server, and the server cannot choose a value that the client did not send. So a client that does not support TLS_FALLBACK_SCSV will not send it, even if the handshake is a fallback from a higher version, and the server will not behave any differently. A client that supports the SCSV and experiences a fallback will send it as one of the supported ciphersuite values; a non-conforming server will simply select one of the other ciphersuites that it supports, ignoring the unknown value.
P.S. TLS_FALLBACK_SCSV was previously called TLS_DOWNGRADE_SCSV in an earlier draft RFC, which indicates its purpose in preventing downgrade attacks. I presume that it was renamed to indicate the action that the client is actually taking: falling back to an older protocol version because of a handshake failure.