i have the same problem whenever i do something like tar'ing up /coda.
this is on a regular ol' 100 meg ethernet network, with no firewalling
or anything else suspect going on.
i'm also not really sure what to do.
On 07/20/04, [EMAIL PROTECTED] wrote:
> I am trying to set up a coda filesys. My experience is that when the
> system works, it's very nice. This is, however, rare. Mostly the system
> acts in flaky & sensitive ways that require constant intervention. Can
> anyone advise me?
>
> I am running all the latest stuff: release 6.0.6-1 on both client & server.
> Server & clients all run on linux boxes. The server has 1Gb of RVM, in a file,
> not a partition, due to hints I've seen in the docs & on the mailing list
> about paging, mmaping, etc. (1Gb of RVM is an undocumented option handled by
> the vice-setup scripts.) The RVM log is 25Mb, on a raw partition. The files
> live in a 400Gb ext3 filesys on /vicepa. For the initial trial, I started with
> my personal music collection -- 9Gb of mp3 & flac files. The mp3 files are
> roughly 1-5 Mb each; the flac files are 5-30Mb each. So: a small number of big
> files.
>
> The server is sitting in a real machine room, with real network connectivity:
> gigabit ethernet to a lan, and a real pipe to the internet from there.
>
> I set up several clients:
> CM: Client "CM" is a linux box sitting behind a standard home cable modem.
> It has constant connectivity ranging up to 1Mb/s.
>
> LOCAL: Client LOCAL is on the server; no network in the picture.
>
> WAN: Client WAN is a linux box sitting on an ethernet in my office at
> Georgia Tech -- no cable-modem between it & the Net.
>
> I mention the cable-modemness of the client connection, because Jan has posted
> earlier saying that the asymmetry of cable-modem bandwidth confuses coda's
> bandwith measurements -- it assumes incoming bandwidth equals outgoing.
>
> -------------------------------------------------------------------------------
> Failure 1:
>
> The first thing I did was copy 9Gb of music files into my coda fs on the LOCAL
> client -- that is, the files were copied from a local ext3 filesys into a coda
> filesys *on the machine where the coda server runs*. This worked, thought it
> was a little weird to see "red zone -- stalling blah blah" messages on such
> net-less operation.
>
> I was able to access these files from client CM & WAN in onesies & twosies
> with no problem. Then I tried, on client WAN (that is, the client that
> communicates with the server over a long-distance Internet connection, but
> doesn't have a wimpy cable modem connecting it to the Net):
>
> find . -type f -exec md5sum {} \;
>
> At first, it ran like a champ. Then it didn't. Here's the tail of the
> recursive md5sum walk:
> 4c507b84f2191ad0c9e8921e0f543ac7 ./affection/cd.db
> 152c03eacd67ba3f28462abcacd85453 ./affection/track08.cdda.flac
> 8cd0cf505aa05c7bebbac9fa94560289 ./affection/track08.cdda.mp3
> 841ab15fa7bde3e019c06f7b0394351d ./affection/audio_02.inf
> 9e6b48f2d7fe648f83bec2a221a8e5d8 ./affection/track11.cdda.flac
> ae7ca0a4a359a8f92d9a079a7cc8e364 ./affection/audio_12.inf
> 0ccaf063cbf89f7345955257d96134ad ./affection/cdp-q
> 4c1d9cc34e790c8fb52975a9973ce10d ./affection/track13.cdda.mp3
> 4f9377b72053579bcb80e59bb5ad610e ./affection/audio_10.inf
> 44e6c8a3596b59f589d934c624141e8d ./affection/track07.cdda.flac
> 9bea35fbbb5f679a8de559bdfd37bf6c ./affection/track10.cdda.mp3
> 4b0fb02ca5944804cc403b6ff1f3797a ./affection/audio_01.inf
> md5sum: ./affection/track05.cdda.flac: Connection timed out
> find: ./affection/audio_08.inf: Connection timed out
> find: ./affection/track05.cdda.mp3: Connection timed out
> find: ./affection/audio_11.inf: Connection timed out
> find: ./rampal1: Connection timed out
> find: ./rampal2: Connection timed out
> find: ./sleepbeauty+toyshop: Connection timed out
> find: ./porter-on-mind: Connection timed out
> find: ./th-md5s: Connection timed out
> find: ./mozart-horn-concerti3: Connection timed out
> find: ./th: Connection timed out
> find: ./algreen: Connection timed out
> find: ./bush-story: Connection timed out
> find: ./mozart-wind-concerti: Connection timed out
> find: ./oconor-piano: Connection timed out
> find: ./eagles-hits: Connection timed out
> find: ./anything-goes-yoyo: Connection timed out
> find: ./beeth-piano1: Connection timed out
>
> Again, note that this lossage occurred on a system with no cable modem, and
> presumably symmetric bandwidth to the server.
>
> -------------------------------------------------------------------------------
> Failure 2:
>
> On client CM -- the system connected to the Net via a home cable-modem --
> I attempted to copy a really large dir of media (about 200Gb) into my coda
> filesys:
>
> cp -prv . /coda/lambda.csail.mit.edu/shivers/music-npx
>
> It managed to copy about 15 files, then codacon began blatting out
>
> Red zone, stalling writer ( 00:33:35 )
>
> messages, and then the client went write-disconnected.
>
> % cfs lv ~/c
> Status of volume 0x7f000000 (2130706432) named "coda:root"
> Volume type is ReadWrite
> Connection State is WriteDisconnected
> Minimum quota is 0, maximum quota is unlimited
> Current blocks used are 10324696
> The partition has 371998976 blocks available out of 382693232
> Write-back is VIOC_STATUSWB: Invalid argument
>
> Note the weirdo final line -- "VIOC_STATUSWB: Invalid argument"? What's that?
>
> During this time, the net connection was completely solid. I mean, I might
> have gotten less than my nominal 1Mb/sec, but the connection was always there.
>
> So the real-world operation of coda here is that if you start writing a lot of
> data, you disconnect, and then your writes just fail. So you can't ever count
> on some operation actually working; it could very easily fail mid-stream.
>
> -------------------------------------------------------------------------------
> Failure 3:
>
> On client CM -- the one connected via cable-modem -- I also did a
>
> find . -type f -exec md5sum {} \;
>
> in the coda dir holding the 9Gb of music. It won for a couple of files, then
> began to barf out msgs like this
>
> md5sum: ./thelonious/track03.cdda.flac: Connection timed out
> find: ./thelonious/track03.cdda.mp3: Connection timed out
> find: ./thelonious/audio_17.inf: Connection timed out
> find: ./thelonious/track07.cdda.mp3: Connection timed out
> .
> .
> .
>
> -------------------------------------------------------------------------------
>
> What I find, in general, is that I cannot rely on file ops completing. Apps
> that access my coda files sometimes win and sometimes seem to drive the
> system into disconnected state, and then I must go through a
> cfs wr
> cfs cs
> cfs lv .
> dance to reconnect. This happens when I am on a client with a completely
> stable connection to the ethernet. We are not talking phone lines here.
> This essentially renders coda unusable.
>
> I tried jacking up the timeout & retry values on the client and server to
> see if that would help. Maybe it did, some. But I am still definitely losing.
>
> I also tried doing a
> cfs strong
> I don't have a super-clear idea of how this would affect my operation --
> the one-line description with the cfs doc is that it prevents the system
> from ever going into weak-connectivity mode, but that doesn't mean it would
> prevent the system from going write-disconnected. In any event, when I do
> this, my client becomes more or less coda-catatonic.
>
> Some questions:
> 1. Am I doing something wrong?
>
> 2. Do other people lose in this way? / Are other people winning?
> I do not see similar reports on this mailing list. Is it that no one
> is hammering on their servers with big files? Is it that no one is
> connecting via cable modems? I don't have a good feeling for how many
> people are really using coda and in what configuations.
>
> 3. Is coda not ready for really big repositories (800Gb filesys, 1Gb rvm
> metadata)?
>
> 4. Any advice at all?
>
> I'm a little dismayed to be losing at such a simple stage of useage. I'm
> not having problems with reintegration conflicts or any of the real voodoo.
> I'm getting hosed just reading & writing files *while connected*.
>
> BTW, I'm also surprised that coda is having problems with asymmetric network
> connections like cable modems in 2004. The lion's share of mobile connections
> these days at private residences is through connections of this sort.
> -Olin
--
steve simitzis : /sim' - i - jees/
pala : saturn5 productions
www.steve.org : 415.282.9979
hath the daemon spawn no fire?
