Does this corruption sound familiar? - Netware

This is a discussion on Does this corruption sound familiar? - Netware ; I work for a small software shop serving a large organization. We (the small shop) develop a fileserver-based application that maintains a number of complex databases, each consisting of lots of indexed files. One of our databases will be shared ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: Does this corruption sound familiar?

  1. Does this corruption sound familiar?

    I work for a small software shop serving a large organization. We
    (the small shop) develop a fileserver-based application that maintains
    a number of complex databases, each consisting of lots of indexed
    files. One of our databases will be shared among many workstations,
    and all of our code is workstation-based (Win32, surprise!) Some of
    our databases reside on Novell servers, some on MS servers, but of
    course the issue here is NetWare.

    We've been noticing a sporadic kind of corruption on our NetWare
    databases for a long time. When I say "a long time", I mean dating
    back to NetWare 3. We're on NetWare 5 now. The IS people in our
    (big) organization who are responsible for our servers tell us we
    can't ask Novell about this problem because the version of NetWare on
    our servers is no longer supported. The IS folks would be happy to
    upgrade us to 6.5, but we're wondering if that will fix our problem.

    Our problem appears to be one of cache corruption on the server. When
    it happens, a contiguous swatch of one of the files in a database will
    *appear* to be all binary zeroes as far as the workstations can see,
    but on the server disk the file will be intact. We can restore the
    workstations' ability to see the underlying file correctly by
    detaching from the file all workstations using the file, and then
    doing something to flush the cache. Rebooting the server obviously
    flushes cache, but so does this, when run from a workstation:

    ren problemfile problemfile.BAD
    xcopy problemfile.BAD problemfile

    As I said, this problem doesn't actually damage data on disk, but it
    badly discommodes our users to have to exit our application while
    someone fixes the server's corrupt idea of part of the database.

    Does this problem look familiar to anyone? Is there any reason to
    think Novell has conquered it in a subsequent release?

    /Lew
    ---
    Lew Perin / perin@acm.org

  2. Re: Does this corruption sound familiar?

    Lewis Perin wrote:

    >I work for a small software shop serving a large organization. We
    >(the small shop) develop a fileserver-based application that maintains
    >a number of complex databases, each consisting of lots of indexed
    >files. One of our databases will be shared among many workstations,
    >and all of our code is workstation-based (Win32, surprise!) Some of
    >our databases reside on Novell servers, some on MS servers, but of
    >course the issue here is NetWare.
    >
    >We've been noticing a sporadic kind of corruption on our NetWare
    >databases for a long time. When I say "a long time", I mean dating
    >back to NetWare 3. We're on NetWare 5 now. The IS people in our
    >(big) organization who are responsible for our servers tell us we
    >can't ask Novell about this problem because the version of NetWare on
    >our servers is no longer supported. The IS folks would be happy to
    >upgrade us to 6.5, but we're wondering if that will fix our problem.
    >
    >Our problem appears to be one of cache corruption on the server. When
    >it happens, a contiguous swatch of one of the files in a database will
    >*appear* to be all binary zeroes as far as the workstations can see,
    >but on the server disk the file will be intact. We can restore the
    >workstations' ability to see the underlying file correctly by
    >detaching from the file all workstations using the file, and then
    >doing something to flush the cache. Rebooting the server obviously
    >flushes cache, but so does this, when run from a workstation:
    >
    > ren problemfile problemfile.BAD
    > xcopy problemfile.BAD problemfile
    >
    >As I said, this problem doesn't actually damage data on disk, but it
    >badly discommodes our users to have to exit our application while
    >someone fixes the server's corrupt idea of part of the database.
    >
    >Does this problem look familiar to anyone? Is there any reason to
    >think Novell has conquered it in a subsequent release?
    >
    >/Lew
    >---
    >Lew Perin / perin@acm.org


    Could the workstation caching setting be involved here? Perhaps disable
    it?

  3. Re: Does this corruption sound familiar?

    Lew,

    You should disable Turbo FAT; it's known to cause corruption in large
    databases, including GroupWise. Check into this TID at Novell

    http://support.novell.com/cgi-bin/se...?/10064734.htm

    subdude



    On 10 Aug 2004 15:44:25 -0400, Lewis Perin graced us
    with:

    >I work for a small software shop serving a large organization. We
    >(the small shop) develop a fileserver-based application that maintains
    >a number of complex databases, each consisting of lots of indexed
    >files. One of our databases will be shared among many workstations,
    >and all of our code is workstation-based (Win32, surprise!) Some of
    >our databases reside on Novell servers, some on MS servers, but of
    >course the issue here is NetWare.
    >
    >We've been noticing a sporadic kind of corruption on our NetWare
    >databases for a long time. When I say "a long time", I mean dating
    >back to NetWare 3. We're on NetWare 5 now. The IS people in our
    >(big) organization who are responsible for our servers tell us we
    >can't ask Novell about this problem because the version of NetWare on
    >our servers is no longer supported. The IS folks would be happy to
    >upgrade us to 6.5, but we're wondering if that will fix our problem.
    >
    >Our problem appears to be one of cache corruption on the server. When
    >it happens, a contiguous swatch of one of the files in a database will
    >*appear* to be all binary zeroes as far as the workstations can see,
    >but on the server disk the file will be intact. We can restore the
    >workstations' ability to see the underlying file correctly by
    >detaching from the file all workstations using the file, and then
    >doing something to flush the cache. Rebooting the server obviously
    >flushes cache, but so does this, when run from a workstation:
    >
    > ren problemfile problemfile.BAD
    > xcopy problemfile.BAD problemfile
    >
    >As I said, this problem doesn't actually damage data on disk, but it
    >badly discommodes our users to have to exit our application while
    >someone fixes the server's corrupt idea of part of the database.
    >
    >Does this problem look familiar to anyone? Is there any reason to
    >think Novell has conquered it in a subsequent release?
    >
    >/Lew
    >---
    >Lew Perin / perin@acm.org



  4. Re: Does this corruption sound familiar?

    U-18@JimWilliamson.net (www.JimWilliamson.net) writes:

    > Lewis Perin wrote:
    >
    > >I work for a small software shop serving a large organization. We
    > >(the small shop) develop a fileserver-based application that maintains
    > >a number of complex databases, each consisting of lots of indexed
    > >files. One of our databases will be shared among many workstations,
    > >and all of our code is workstation-based (Win32, surprise!) Some of
    > >our databases reside on Novell servers, some on MS servers, but of
    > >course the issue here is NetWare.
    > >
    > >We've been noticing a sporadic kind of corruption on our NetWare
    > >databases for a long time. When I say "a long time", I mean dating
    > >back to NetWare 3. We're on NetWare 5 now. The IS people in our
    > >(big) organization who are responsible for our servers tell us we
    > >can't ask Novell about this problem because the version of NetWare on
    > >our servers is no longer supported. The IS folks would be happy to
    > >upgrade us to 6.5, but we're wondering if that will fix our problem.
    > >
    > >Our problem appears to be one of cache corruption on the server. When
    > >it happens, a contiguous swatch of one of the files in a database will
    > >*appear* to be all binary zeroes as far as the workstations can see,
    > >but on the server disk the file will be intact. We can restore the
    > >workstations' ability to see the underlying file correctly by
    > >detaching from the file all workstations using the file, and then
    > >doing something to flush the cache. Rebooting the server obviously
    > >flushes cache, but so does this, when run from a workstation:
    > >
    > > ren problemfile problemfile.BAD
    > > xcopy problemfile.BAD problemfile
    > >
    > >As I said, this problem doesn't actually damage data on disk, but it
    > >badly discommodes our users to have to exit our application while
    > >someone fixes the server's corrupt idea of part of the database.
    > >
    > >Does this problem look familiar to anyone? Is there any reason to
    > >think Novell has conquered it in a subsequent release?

    >
    > Could the workstation caching setting be involved here? Perhaps disable
    > it?


    I doubt it; this has the aroma of a server problem. While it would be
    rash of me to claim that *all* workstations have caching disabled,
    once a swatch of zeroes gets established in the server cache of a
    file, that's the way it looks to *all* workstations, including ones
    with caching disabled.

    /Lew
    ---
    Lew Perin / perin@acm.org
    http://www.panix.com/~perin/babelcarp.html

  5. Re: Does this corruption sound familiar?

    subdude writes:

    > [...sporadic corruption apparently in server cache not on disk...]
    >
    > You should disable Turbo FAT; it's known to cause corruption in large
    > databases, including GroupWise. Check into this TID at Novell
    >
    > http://support.novell.com/cgi-bin/se...?/10064734.htm


    Thanks very much. This looks like the problem, for in the predecessor
    TID to this one

    http://support.novell.com/cgi-bin/se...gi?2960009.htm

    the symptoms entry says

    If one dismounts the volume with the corrupt file or uses DOS
    COPY.EXE to copy the file to another name or same name in another
    directory, the resultant file is no longer corrupt.

    One other thing, though: will disabling Turbo FAT compromise system
    performance at all?

    /Lew
    ---
    Lew Perin / perin@acm.org
    http://www.panix.com/~perin/babelcarp.html

  6. Re: Does this corruption sound familiar?

    On 10 Aug 2004 15:44:25 -0400, Lewis Perin wrote:
    > We've been noticing a sporadic kind of corruption on our NetWare
    > databases for a long time. When I say "a long time", I mean dating
    > back to NetWare 3. We're on NetWare 5 now. The IS people in our
    > (big) organization who are responsible for our servers tell us we
    > can't ask Novell about this problem because the version of NetWare on
    > our servers is no longer supported. The IS folks would be happy to
    > upgrade us to 6.5, but we're wondering if that will fix our problem.


    Certainly it would make sense to test your application against current
    code. If you really are still using v5.0, you're several major releases
    behind. In addition to new features, new versions generally fix problems
    found in older versions.


    > Our problem appears to be one of cache corruption on the server. When
    > it happens, a contiguous swatch of one of the files in a database will
    > *appear* to be all binary zeroes as far as the workstations can see,
    > but on the server disk the file will be intact.


    This *could* also be a "sparse" file being created, due to a bug in your
    application, or due to a bug in the client that you're using to talk to the
    server.


    > As I said, this problem doesn't actually damage data on disk


    This tends to indicate to me that "Turbo FAT corruption", as suggested by
    others, may not be your problem.


    > Does this problem look familiar to anyone? Is there any reason to
    > think Novell has conquered it in a subsequent release?


    Yes. You can find out for sure, though, by putting up a current version
    (NetWare 6.5) server, with the current service pack installed, and using
    the most recent version of the Client (v4.9) with it's most recent service
    pack. Disable Oplocks and Client Side Caching, then test your application.
    If you still have trouble, then at least you'll have something recent and
    supported to work with.


    --
    | David Gersic dgersic_@_niu.edu |
    | Karaoke is a Japanese word meaning "tone deaf". |
    | Email address is munged to avoid spammers. Remove the underscores. |

  7. Re: Does this corruption sound familiar?

    David Gersic writes:

    > [...Upgrade the server!...]
    >
    > > Our problem appears to be one of cache corruption on the server. When
    > > it happens, a contiguous swatch of one of the files in a database will
    > > *appear* to be all binary zeroes as far as the workstations can see,
    > > but on the server disk the file will be intact.

    >
    > This *could* also be a "sparse" file being created, due to a bug in your
    > application, or due to a bug in the client that you're using to talk to the
    > server.


    Our application doesn't put the zeroes in. The zeroes exist only in
    server cache. As I said, the file on disk is intact.

    > > As I said, this problem doesn't actually damage data on disk

    >
    > This tends to indicate to me that "Turbo FAT corruption", as suggested by
    > others, may not be your problem.


    Sorry, but I think you have it backwards here. According to

    http://support.novell.com/cgi-bin/se...gi?2960009.htm

    (which is the predecessor page to the current Turbo-FAT-disable TID
    page)

    One method of verifying that the STATUS 2 BTRIEVE errors are caused
    by a corrupt turbo FAT is to use the DOS COPY.EXE to copy the
    corrupt file to a new directory or different name in the same
    directory. If the resultant file is no longer corrupt, then the test
    proves that the turbo FAT was corrupt and the TURBODIS.NLM file
    should be applied. If the same corrupt file is copied using
    NetWare's NCOPY.EXE, the resultant file will still be corrupt[...]

    I've nothing against upgrading to 6.5, but I can see no indication at
    support.novell.com that 6.5 fixes the Turbo FAT bug, and the page I
    cited above (from April '02 - prior to 6.5?) indicates that the
    disable patch applies to everything from 4.10 through 6.0.

    /Lew
    ---
    Lew Perin / perin@acm.org
    http://www.panix.com/~perin/babelcarp.html

  8. Re: Does this corruption sound familiar?

    On 11 Aug 2004 15:45:03 -0400, Lewis Perin graced us
    with:


    >I've nothing against upgrading to 6.5, but I can see no indication at
    >support.novell.com that 6.5 fixes the Turbo FAT bug, and the page I
    >cited above (from April '02 - prior to 6.5?) indicates that the
    >disable patch applies to everything from 4.10 through 6.0.
    >
    >/Lew
    >---
    >Lew Perin / perin@acm.org
    >http://www.panix.com/~perin/babelcarp.html


    No need to upgrade to 6.5 (other than numerous feature enchancements
    ) for a solution to this problem as TurboFAT is still an issue.
    The performance difference will be negligible at best and is a fair
    trade off to losing/corrupting your db.

    I still disable this on GW servers for my clients and they never know
    the difference (with the exception of the fact that their dbs/GW
    systems are now more reliable).

    subdude

  9. Re: Does this corruption sound familiar?

    "Lewis Perin " wrote in comp.os.netware.misc:

    [sNip]
    > We've been noticing a sporadic kind of corruption on our NetWare
    > databases for a long time. When I say "a long time", I mean dating
    > back to NetWare 3. We're on NetWare 5 now. The IS people in our
    > (big) organization who are responsible for our servers tell us we
    > can't ask Novell about this problem because the version of NetWare on
    > our servers is no longer supported. The IS folks would be happy to
    > upgrade us to 6.5, but we're wondering if that will fix our problem.
    >
    > Our problem appears to be one of cache corruption on the server. When
    > it happens, a contiguous swatch of one of the files in a database will
    > *appear* to be all binary zeroes as far as the workstations can see,
    > but on the server disk the file will be intact. We can restore the
    > workstations' ability to see the underlying file correctly by
    > detaching from the file all workstations using the file, and then
    > doing something to flush the cache. Rebooting the server obviously
    > flushes cache, but so does this, when run from a workstation:
    >
    > ren problemfile problemfile.BAD
    > xcopy problemfile.BAD problemfile
    >
    > As I said, this problem doesn't actually damage data on disk, but it
    > badly discommodes our users to have to exit our application while
    > someone fixes the server's corrupt idea of part of the database.

    [sNip]

    For NetWare 4.x and above, you may need to disable SubAllocation on
    the file's that the database stores the data in. To do this, you can
    simply flag the files with the "DS" attribute using Novell's FLAG command
    as follows:

    FLAG filename.ext +DS

    If compression is enabled on the volume, then disable that for the
    file as well:

    FLAG filename.ext +DC

    You can do both at once with this DOS command:

    FLAG filename.ext +DC +DS

  10. Re: Does this corruption sound familiar?

    Randolf Richardson writes:

    > "Lewis Perin " wrote in comp.os.netware.misc:
    >
    > [...server cache corruption without corruption of data on disk...]
    >
    > For NetWare 4.x and above, you may need to disable SubAllocation on
    > the file's that the database stores the data in. To do this, you can
    > simply flag the files with the "DS" attribute using Novell's FLAG command
    > as follows:
    >
    > FLAG filename.ext +DS
    >
    > If compression is enabled on the volume, then disable that for the
    > file as well:
    >
    > FLAG filename.ext +DC
    >
    > You can do both at once with this DOS command:
    >
    > FLAG filename.ext +DC +DS


    Thanks for helping. But both suballocation and compression are
    clearly there to enhance server performance, so the thought of
    eliminating them doesn't make my heart sing. You have evidence for
    the necessity and sufficiency of your solution(s), right?

    /Lew
    ---
    Lew Perin / perin@acm.org
    http://www.panix.com/~perin/babelcarp.html

  11. Re: Does this corruption sound familiar?

    "Lewis Perin " wrote in comp.os.netware.misc:

    > Randolf Richardson writes:
    >
    >> "Lewis Perin " wrote in comp.os.netware.misc:
    >>
    >> [...server cache corruption without corruption of data on disk...]
    >>
    >> For NetWare 4.x and above, you may need to disable SubAllocation on
    >> the file's that the database stores the data in. To do this, you can
    >> simply flag the files with the "DS" attribute using Novell's FLAG
    >> command as follows:
    >>
    >> FLAG filename.ext +DS
    >>
    >> If compression is enabled on the volume, then disable that for the
    >> file as well:
    >>
    >> FLAG filename.ext +DC
    >>
    >> You can do both at once with this DOS command:
    >>
    >> FLAG filename.ext +DC +DS

    >
    > Thanks for helping. But both suballocation and compression are
    > clearly there to enhance server performance, so the thought of
    > eliminating them doesn't make my heart sing.


    I wasn't suggesting disabling these features at the volume level,
    rather I was just recommending you disable them for the database files
    only.

    Both Compression and SubAllocation are useful, but when it comes to
    databases Compression should not be used (otherwise it will slow down
    database access), and there's no point to using SubAllocation since
    database files tend to be larger files anyway (SubAllocation is really more
    useful when you have many small files, or for that matter just one heck of
    a lot of files period).

    If a file is flagged DC, then it won't be compressed (but if it's
    already compressed then you'll have to copy it to NULL a few times to force
    NetWare to switch it over to a decompressed state, at least that's the
    simple way of doing it).

    If a file is flagged DS, then it won't be SubAllocated, and no other
    SubAllocated data will be merged onto the tail ends of the sectors it
    occupies.

    > You have evidence for
    > the necessity and sufficiency of your solution(s), right?


    Heheh, yeah, personal experience. I shall pick one in particular
    which will probably be of great interest to you...

    Once I was experiencing problems with occasional tablespace corruption
    in Oracle 8 on NetWare, but after flagging the tablespace files with the DC
    and DS attributes the corruption was gone. Later I found out that Oracle
    even recommended against placing a tablespace on a volume that supports
    Compression and/or SubAllocation because, as it turns out, Oracle is able
    to achieve file sizes of up to 512 PetaBytes on a TFS (Traditional File
    System) volume because it accesses the disk more directly (thus if the
    tablespace is Compressed and/or SubAllocated, then decompressed and/or
    unparsed versions of the data get loaded instead of what is expected).

    If you'd like to verify my many years of experience, feel free to
    search in Google for my current and previous names and you'll see that I've
    been quite active in the Novell communities for a long time:

    - "Randolf Richardson"
    - "Randy Richardson"

    I hope that helps.

  12. Re: Does this corruption sound familiar?

    Randolf Richardson writes:

    > "Lewis Perin " wrote in comp.os.netware.misc:
    >
    > > Randolf Richardson writes:
    > >
    > >> "Lewis Perin " wrote in comp.os.netware.misc:
    > >>
    > >> > [...server cache corruption without corruption of data on disk...]
    > >>
    > >> [...disabling suballocation and compression...]

    > >
    > > Thanks for helping. But both suballocation and compression are
    > > clearly there to enhance server performance, so the thought of
    > > eliminating them doesn't make my heart sing.

    >
    > I wasn't suggesting disabling these features at the volume level,
    > rather I was just recommending you disable them for the database files
    > only.
    >
    > Both Compression and SubAllocation are useful, but when it comes to
    > databases Compression should not be used (otherwise it will slow down
    > database access), and there's no point to using SubAllocation since
    > database files tend to be larger files anyway (SubAllocation is really more
    > useful when you have many small files, or for that matter just one heck of
    > a lot of files period).


    We have lots (hundreds) of files in one of our databases, some of
    which are big (> TB), some small (few kB.)

    > If a file is flagged DC, then it won't be compressed (but if it's
    > already compressed then you'll have to copy it to NULL a few times to force
    > NetWare to switch it over to a decompressed state, at least that's the
    > simple way of doing it).
    >
    > If a file is flagged DS, then it won't be SubAllocated, and no other
    > SubAllocated data will be merged onto the tail ends of the sectors it
    > occupies.


    And if FLAG shows nothing under "Netware Attr" and "Mode", both
    compression and suballocation are in effect? (That's what I see for
    the files that constitute one of our databases.)

    > > You have evidence for
    > > the necessity and sufficiency of your solution(s), right?

    >
    > Heheh, yeah, personal experience. I shall pick one in particular
    > which will probably be of great interest to you...
    >
    > Once I was experiencing problems with occasional tablespace corruption
    > in Oracle 8 on NetWare, but after flagging the tablespace files with the DC
    > and DS attributes the corruption was gone. Later I found out that Oracle
    > even recommended against placing a tablespace on a volume that supports
    > Compression and/or SubAllocation because, as it turns out, Oracle is able
    > to achieve file sizes of up to 512 PetaBytes on a TFS (Traditional File
    > System) volume because it accesses the disk more directly (thus if the
    > tablespace is Compressed and/or SubAllocated, then decompressed and/or
    > unparsed versions of the data get loaded instead of what is expected).


    The reason the Turbo FAT Disable patch looked useful (by the way, we
    have already applied it) was that its writeup fit the signature of the
    problem (only on large files; and not on disk, only in cache.) Was
    the file OK on disk in your Oracle problem?

    > If you'd like to verify my many years of experience, feel free to
    > search in Google for my current and previous names and you'll see that I've
    > been quite active in the Novell communities for a long time:
    > [...]


    I hope you don't think I was challenging your competence or your good
    intentions. I was asking you to convince me that your solution
    helps with my specific type of corruption.

    /Lew
    ---
    Lew Perin / perin@acm.org
    http://www.panix.com/~perin/babelcarp.html

  13. Re: Does this corruption sound familiar?

    On 11 Aug 2004 15:45:03 -0400, Lewis Perin wrote:
    > David Gersic writes:
    >
    >> [...Upgrade the server!...]


    Well, you might try it and report back. If not, there's not much else I can
    tell you. I shut our last NW4 server down about 4 years ago. Our NW5.1
    servers are on their way out. Even NW6 is probably not going to last long,
    as we're upgrading everything to NW6.5.


    > Sorry, but I think you have it backwards here. According to
    >
    > http://support.novell.com/cgi-bin/se...gi?2960009.htm


    Noting the first couple of lines under "Symptoms":

    NetWare customers may see BTRIEVE applications report
    STATUS 2 errors and those who use the Revelation LH.NLM
    report Group Format Errors (GFE). The issue may also be
    seen on Groupwise databases.

    Are you using Btrieve, Revelation, or GroupWise?

    Note that in all three cases, access to the data files is via a backend
    database manager that is actually running on the server (btrieve.nlm,
    lh.nlm, or GroupWise). From your description, you're not using any such
    thing, you're just using the regular file system calls.

    I'm not saying it _can't_ be, I'm just saying I doubt it. Since you have
    the server, and the application, and can apparantly reproduce the problem,
    give the turbodis.nlm fix a try and see if it helps. If it does, great, but
    I'll be surprised.

    If it does, I'm also curious to know if you have the same problem with
    your database on an NSS file system volume.

    We've been running GroupWise here since it was WordPerfect Office, and I
    have not seen problems like this with it.

    If you can't upgrade your test server to NetWare 6.5, I'd be happy to set
    you up with access to a test server here to try your application against.
    Or you can send me the application and notes on how to reproduce the
    problem, and I'll test it. If the bug, whatever it is, is in NetWare, I
    want to see it get fixed.



    --
    | David Gersic dgersic_@_niu.edu |
    | Christmas: If you don't give, you don't get it. |
    | Email address is munged to avoid spammers. Remove the underscores. |

  14. Re: Does this corruption sound familiar?

    David Gersic writes:

    > On 11 Aug 2004 15:45:03 -0400, Lewis Perin wrote:
    > > David Gersic writes:
    > >
    > >> [...Upgrade the server!...]

    >
    > Well, you might try it and report back. If not, there's not much else I can
    > tell you. I shut our last NW4 server down about 4 years ago. Our NW5.1
    > servers are on their way out. Even NW6 is probably not going to last long,
    > as we're upgrading everything to NW6.5.


    I'm sure we'll upgrade, but the Turbo FAT bug seems to have persisted
    into NW6, so applying the patch seemed to us both more urgent and more
    conservative.

    > > Sorry, but I think you have it backwards here. According to
    > >
    > > http://support.novell.com/cgi-bin/se...gi?2960009.htm

    >
    > Noting the first couple of lines under "Symptoms":
    >
    > NetWare customers may see BTRIEVE applications report
    > STATUS 2 errors and those who use the Revelation LH.NLM
    > report Group Format Errors (GFE). The issue may also be
    > seen on Groupwise databases.
    >
    > Are you using Btrieve, Revelation, or GroupWise?


    No. In any case, our application has its own symptoms, which probably
    aren't of general interest. What underlies our app's symptoms, as
    I've said before, is suddenly seeing a large contiguous swatch of a
    file turn to all binary zeroes (in cache, not on the server's disk.)

    > Note that in all three cases, access to the data files is via a backend
    > database manager that is actually running on the server (btrieve.nlm,
    > lh.nlm, or GroupWise). From your description, you're not using any such
    > thing, you're just using the regular file system calls.


    True enough.

    > I'm not saying it _can't_ be, I'm just saying I doubt it. Since you have
    > the server, and the application, and can apparantly reproduce the problem,
    > give the turbodis.nlm fix a try and see if it helps. If it does, great, but
    > I'll be surprised.


    It was applied Friday night. So far so good, but it's way to early to
    celebrate.

    > If it does, I'm also curious to know if you have the same problem with
    > your database on an NSS file system volume.


    Does NSS make this moot by not using Turbo FAT at all?

    > We've been running GroupWise here since it was WordPerfect Office, and I
    > have not seen problems like this with it.
    >
    > If you can't upgrade your test server to NetWare 6.5, I'd be happy to set
    > you up with access to a test server here to try your application against.
    > Or you can send me the application and notes on how to reproduce the
    > problem, and I'll test it. If the bug, whatever it is, is in NetWare, I
    > want to see it get fixed.


    That's very generous of you. (It's also generous of you to try to
    figure this out with me, of course.) But we'll be able to try 6.5 out
    in-house, which should be easier on both you and me.

    /Lew
    ---
    Lew Perin / perin@acm.org
    http://www.panix.com/~perin/babelcarp.html

  15. Re: Does this corruption sound familiar?

    On 17 Aug 2004 15:24:03 -0400, Lewis Perin wrote:
    >> If it does, I'm also curious to know if you have the same problem with
    >> your database on an NSS file system volume.

    >
    > Does NSS make this moot by not using Turbo FAT at all?


    Yes. The NSS file system was a ground up new development, and doesn't use
    any of the Traditional File System (TFS) code as far as I know. So, it'd be
    interesting to see if your app runs in to the same problems or not using
    NSS.

    > That's very generous of you. (It's also generous of you to try to
    > figure this out with me, of course.) But we'll be able to try 6.5 out
    > in-house, which should be easier on both you and me.


    Let us know how it turns out.


    --
    | David Gersic dgersic_@_niu.edu |
    | Programmer (n): One who makes the lies the salesman told come true. |
    | Email address is munged to avoid spammers. Remove the underscores. |

  16. Re: Does this corruption sound familiar?

    Lewis Perin writes:

    > [...server cache corruption...]


    Normally I wouldn't follow up my own post, but, since my problem took
    up a fair amount of attention on this newsgroup, I think I should
    announce that I'm fairly confident it's been solved. We applied the
    Turbo FAT Disable patch two-and-a-half weeks ago, and there hasn't
    been a whisper of a recurrence of the cache corruption. Thanks to all
    who wrote to offer help, even the ones who disagreed with the solution
    we adopted!

    /Lew
    ---
    Lew Perin / perin@acm.org
    http://www.panix.com/~perin/babelcarp.html

  17. Re: Does this corruption sound familiar?

    On 31 Aug 2004 09:40:01 -0400, Lewis Perin wrote:
    > Lewis Perin writes:
    >
    >> [...server cache corruption...]

    >
    > Normally I wouldn't follow up my own post, but, since my problem took
    > up a fair amount of attention on this newsgroup, I think I should
    > announce that I'm fairly confident it's been solved.


    Interesting. Thanks for the update. Now, can I talk you in to testing it on
    NW65 with NSS?

    --
    | David Gersic dgersic_@_niu.edu |
    | Perform random silliness and senseless acts of confusion. |
    | Email address is munged to avoid spammers. Remove the underscores. |

  18. Re: Does this corruption sound familiar?

    On 31 Aug 2004 09:40:01 -0400, Lewis Perin graced us
    with:

    >Lewis Perin writes:
    >
    >> [...server cache corruption...]

    >
    >Normally I wouldn't follow up my own post, but, since my problem took
    >up a fair amount of attention on this newsgroup, I think I should
    >announce that I'm fairly confident it's been solved. We applied the
    >Turbo FAT Disable patch two-and-a-half weeks ago, and there hasn't
    >been a whisper of a recurrence of the cache corruption. Thanks to all
    >who wrote to offer help, even the ones who disagreed with the solution
    >we adopted!
    >
    >/Lew
    >---
    >Lew Perin / perin@acm.org
    >http://www.panix.com/~perin/babelcarp.html


    Lew,

    Glad I could be of service!

    subdude

  19. Re: Does this corruption sound familiar?

    David Gersic writes:

    > On 31 Aug 2004 09:40:01 -0400, Lewis Perin wrote:
    > > Lewis Perin writes:
    > >
    > >> [...server cache corruption...]

    > >
    > > Normally I wouldn't follow up my own post, but, since my problem took
    > > up a fair amount of attention on this newsgroup, I think I should
    > > announce that I'm fairly confident it's been solved.

    >
    > Interesting. Thanks for the update. Now, can I talk you in to testing it on
    > NW65 with NSS?


    You don't need to talk me into it. We will be going to 6.5, fairly
    soon, I think.

    /Lew
    ---
    Lew Perin / perin@acm.org
    http://www.panix.com/~perin/babelcarp.html

+ Reply to Thread