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 va
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
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! S
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
>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(
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 th
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? 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 1
>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:
fflush(
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
responsibilit
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 pr
Thomas Nau writes:
> 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
12 matches
Mail list logo
