| Bill Todd 2004-10-21, 5:45 pm |
|
"Arne Joris" <arne@Arden.ed.shawcable.net> wrote in message
news:v5Qdd.790510$M95.165193@pd7tw1no...
> Bill Todd wrote:
....
>
>
> I imagine the indirection of going to a directory server to look up the
> server owning the meta data *can* introduce extra latency (over the WAN)
> plus cpu cycles for non-metadata intensive workloads.
Since in the absence of active contention it goes to the directory server
only once per file or directory accessed, that latency (which should be less
than a single disk access) should usually be negligible.
....
it sounds like the distributed meta data service would create a
> more site aware solution than the single meta data server model, just by
> virtue of doing all meta data operations at the site where the data is
> produced or consumed.
Not really: where the metadata is processed has relatively little to do
with what disk it's obtained from, unless the system goes to some
essentially orthogonal effort to access the most local copy available.
>
> Now for my traffic, I have a writer at site 1, and several readers at
> both sites 1 and 2. So really the data is being accessed at both sites,
> so we'll have to go over the WAN regardless of where the metadata is
> kept.
It doesn't sound as if you really care much about remote metadata access, at
least as long as the amount of metadata processed is negligible compared
with the amount of data fetched. Inter-site latencies tend not to become
*really* noticeable until distances in the hundreds of miles are involved
(100 miles being on the order of a millisecond, one-way).
And if you're mostly reading large files sequentially, it doesn't sound as
if latency should be any real concern there, either. But unless you've got
unlimited bandwidth between the two sites, your desire to do reads locally
is understandable.
- bill
|