7 Replies Latest reply: Dec 2, 2008 7:06 PM by V.J.
V.J. Level 1 Level 1 (0 points)
We are running Xserver MDC with Xsan version 1.4.1 OSX 10.4.1
Couple of clients installed Leopard.
Can this cause instability and ultimately MDC crash?
VJ

Mac OS X (10.4.1)
  • 1. Re: Xsan-OSX versions compatiblity
    Donald Kok Level 2 Level 2 (490 points)
    We had your configuration and it was not so stable.
    We upgraded to other MDC hardware, installed leopard on it with xsan 2.1.
    It is very stable for 2 months now.

    My 2 cents
    Regards
    Donald
  • 2. Re: Xsan-OSX versions compatiblity
    Mathieu Mauser Level 2 Level 2 (210 points)
    It shouldn't cause your MDC to crash at all. Ran a similar set up for over a month or more. Xserves running Tiger Server (10.4.11) and Xsan 1.4.2 with half Tiger 10.4.11 clients and half Leopard 10.5.2 clients. Worked very well.
  • 3. Re: Xsan-OSX versions compatiblity
    Donald Kok Level 2 Level 2 (490 points)
    It shouldn't cause your MDC to crash at all.

    I know it shouldn't, but it did. Noughty mdc.
    It run fine for half a year, and then not anymore.
  • 4. Re: Xsan-OSX versions compatiblity
    MLNNASH Level 1 Level 1 (35 points)
    Run Software Update? - I mean really??


    1.4.1 and 10.4.1 are you serious? Or will your key board not type to 1s?


    MLNNASH
  • 5. Re: Xsan-OSX versions compatiblity
    V.J. Level 1 Level 1 (0 points)
    Hey, that was funny.
    I have other excuses, not the keyboard. Xsan and production workflow is tied to other software that is not certified for new version of the quicktime (and other incompatibilies, and budget....)
    Notice that we did not upgrade Xsan to 1.4.2 (we have 1.4.1)

    Anyway the Apple recommends that none of the clients have version newer that the server versions.
    vj

    <Edited by Moderator>
  • 6. Re: Xsan-OSX versions compatiblity
    MrHoffman Level 6 Level 6 (12,455 points)
    The usual discussion I have with management (I deal with enterprise customers, and they paint themselves into this class of corner with some regularity) is around the trade-offs with running old software in production; what happens if (when?) it all tips over.

    There's no good answer.

    You're stuck here with a conflict in the business requirements here (the changing Mac OS X configuration appears to be effectively or explicitly uncertified), and that usually means raising a management interrupt and requesting management guidance in breaking a deadlock of management creation.

    There's no good technical answer to these management questions.
  • 7. Re: Xsan-OSX versions compatiblity
    V.J. Level 1 Level 1 (0 points)
    I see it this way. My job is to maintain project workflow stable and reliable. So I run cvfck until my file system went from 'dirty' to 'clean', and disconnected Leopard Xsan clients.
    Then I upgraded Xsan to 1.4.2. Before that I had to upgrade OSX from 10.4.9 to 10.4.11. Before that I had to upgrade some EFI and other software upgrades (that made me nervous!)
    Then I upgraded all Tiger clients to xsan 1.4.2
    All in all it was smooth and all xsan volumes mounted on the clients computers.
    Then on Monday I found out that most of the clients not only are unable to open their FCP project files but it also corrupts the files they tried to open.
    It turns that ACL file permission had to be set to 'full' access (it was set before to 'read and write').
    VJ