Hello Thomas,
Saturday, March 24, 2007, 1:06:47 AM, you wrote:
The problem is that the failure modes are very different for networks and
presumably reliable local disk connections. Hence NFS has a lot of error
handling code and provides well understood error handling semantics. Maybe
what
Hi Robert,
On Sun, 25 Mar 2007, Robert Milkowski wrote:
The problem is that the failure modes are very different for networks and
presumably reliable local disk connections. Hence NFS has a lot of error
handling code and provides well understood error handling semantics. Maybe
what you really
On Mar 25, 2007, at 06:14, Thomas Nau wrote:
We use a cluster ;) but in the backend it doesn't solve the sync
problem as you mention
The StorageTek Availability Suite was recently open-sourced:
http://www.opensolaris.org/os/project/avs/
___
Thomas Nau [EMAIL PROTECTED] wrote:
fflush(fp);
fsync(fileno(fp));
fclose(fp);
and check errors.
(It's remarkable how often people get the above sequence wrong and only
do something like fsync(fileno(fp)); fclose(fp);
Thanks for clarifying! Seems I really need to
On March 23, 2007 11:06:33 PM -0700 Adam Leventhal [EMAIL PROTECTED] wrote:
On Fri, Mar 23, 2007 at 11:28:19AM -0700, Frank Cusack wrote:
I'm in a way still hoping that it's a iSCSI related Problem as
detecting dead hosts in a network can be a non trivial problem and it
takes quite some time
On Sat, Mar 24, 2007 at 11:20:38AM -0700, Frank Cusack wrote:
iscsi doesn't use TCP, does it? Anyway, the problem is really transport
independent.
It does use TCP. Were you thinking UDP?
or its own IP protocol. I wouldn't have thought iSCSI would want to be
subject to the vagaries of
Dear all.
I've setup the following scenario:
Galaxy 4200 running OpenSolaris build 59 as iSCSI target; remaining
diskspace of the two internal drives with a total of 90GB is used as zpool
for the two 32GB volumes exported via iSCSI
The initiator is an up to date Solaris 10 11/06 x86 box
On Fri, 23 Mar 2007, Roch - PAE wrote:
I assume the rsync is not issuing fsyncs (and it's files are
not opened O_DSYNC). If so, rsync just works against the
filesystem cache and does not commit the data to disk.
You might want to run sync(1M) after a successful rsync.
A larger rsync would
On March 23, 2007 6:51:10 PM +0100 Thomas Nau [EMAIL PROTECTED] wrote:
Thanks for the hints but this would make our worst nightmares become
true. At least they could because it means that we would have to check
every application handling critical data and I think it's not the apps
I'd tend to disagree with that. POSIX/SUS does not guarantee data makes
it to disk until you do an fsync() (or open the file with the right flags,
or other techniques). If an application REQUIRES that data get to disk,
it really MUST DTRT.
Indeed; want your data safe? Use:
Thomas Nau wrote:
Dear all.
I've setup the following scenario:
Galaxy 4200 running OpenSolaris build 59 as iSCSI target; remaining
diskspace of the two internal drives with a total of 90GB is used as
zpool for the two 32GB volumes exported via iSCSI
The initiator is an up to date Solaris 10
Dear Fran Casper
I'd tend to disagree with that. POSIX/SUS does not guarantee data makes
it to disk until you do an fsync() (or open the file with the right flags,
or other techniques). If an application REQUIRES that data get to disk,
it really MUST DTRT.
Indeed; want your data safe?
Richard,
Like this?
disk--zpool--zvol--iscsitarget--network--iscsiclient--zpool--filesystem--app
exactly
I'm in a way still hoping that it's a iSCSI related Problem as detecting
dead hosts in a network can be a non trivial problem and it takes quite
some time for TCP to timeout and inform
Thanks for clarifying! Seems I really need to check the apps with truss or
dtrace to see if they use that sequence. Allow me one more question: why
is fflush() required prior to fsync()?
When you use stdio, you need to make sure the data is in the
system buffers prior to call fsync.
fclose()
On Fri, Mar 23, 2007 at 11:28:19AM -0700, Frank Cusack wrote:
I'm in a way still hoping that it's a iSCSI related Problem as detecting
dead hosts in a network can be a non trivial problem and it takes quite
some time for TCP to timeout and inform the upper layers. Just a
guess/hope here that
15 matches
Mail list logo
