Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4D91AD15.8000603@gpslsolutions.com>
References: <4D91AD15.8000603@gpslsolutions.com>
Date: Wed, 30 Mar 2011 23:20:23 +1300
Message-ID: <AANLkTikz=8Udk47d2H=UzPY5KT1Odc+JKfbkdUF-H42N@mail.gmail.com>
Subject: Re: CouchDB over a Windows network drive
From: Dave Cottlehuber <dave@muse.net.nz>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 29 March 2011 22:57, Rob Pettefar <rpettefar@gpslsolutions.com> wrote:
> =A0Hi guys
> I have just been trying out a way of storing the actual database and view=
s
> files on a different drive to the application (the final setup needed is =
for
> the majority of data to be held on a NAS system).

Hey Rob,

the short answer is to use either iSCSI or FC LUN not NFS/SMB/whatever else=
.
Mount this via ntfs reparse points (junctions) in the same place as
the original locations.

Or alternatively install the app + dbs + views all on the LUN, after
assigning a drive letter to it.

Longer answer follows after similar trial and error to you.

> This has lead me to find strange behaviour when using storage over a Wind=
ows
> network. If a network address is used, eg "\\computer\couch" which result=
ed
> in CouchDB working except that any databases created will not actually ex=
ist
> in the system once they have been navigated away from (I was using Futon =
for
> database creation and navigation).

Are you doing something like this?

install couchdb to C:\Program Files\Apache Software Foundation\CouchDB
or whereever on a local drive.
modify local.ini directly or via futon:

[couchdb]
database_dir =3D //server/couch_share/var/lib/couchdb
view_index_dir =3D  //server/couch_share/var/lib/couchdb

run couchdb.bat

Log into futon.
create a couch
close & reopen futon
the couch is missing?

Actually it seems the couch is deposited in c:\server\couch_share\
...etc not on the NAS as one would hope. Interestingly the same
approach for couch.log works just fine and logs appear on the
//server/share.

I think somewhere near
get_full_filename(Server, DbName) ->
    filename:join([Server#server.root_dir, "./" ++ DbName ++ ".couch"]).
something goes wrong.

> Further, mapping the area to a network drive seems to cause the "Firefox
> can't establish a connection to the server" page to pop up if the IP + po=
rt
> is entered.
>
> The only way I have found to allow me to have CouchDBs databases to be he=
ld
> in a different location to the server is to install it on the network dri=
ve
> and run it from there.

Technically ok; but over SMB performance will not be good. Not advised
as a solution.

> Am I doing things wrong or is network storage a genuine problem with
> CouchDB?

I am thinking the former. 10Gib iSCSI or FC LUN is going to be fast
enough - people run virtualisation off these too... Using an SMB share
is going to give you grief - there's too much overhead compared to a
local volume or an exported LUN. It is also possible that some of the
file io semantics are different too.

Erlang can access remote volumes - so this is all couch internals
causing us issues.

1> pwd().
C:/couch/1.0.2_R14B02_COUCHDB-963/bin
ok
2> cd("//build/remote").
//build/remote
ok
3>ls().
shared

Basically CouchDB expects all its DBs to be in location specified in
the config file default.ini unless over-ridden by your custom entries
in local.ini.I see nothing technically wrong if your NAS is grunty
enough and my caveats above, to modify local.ini but I suggest using a
block device not a fileshare for performance, and reparse points to
keep the config file simple.

There are a few bugs related to using windows drive letters
https://issues.apache.org/jira/browse/COUCHDB-307. I will look into
these once the current windows-related showstoppers are resolved. You
can get away with using reparse points and then / refers to the root
of the volume couchdb was installed to.....

Cheers
Dave