[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference decwet::windows-nt

Title:Windows NT
Notice:See note 15.0 for HCL location
Moderator:TARKIN::LIN.com::FOLEY
Created:Thu Oct 31 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6086
Total number of notes:31449

5885.0. "Intel, then Alpha, on same HSZ" by BEET::EAGAN (Among the fashion impaired...) Mon Apr 07 1997 07:38

  I have a customer who's interested in the HSZ50s on WNT for a large 
  amount of storage.  Initially, they're interested in the HSZ connected
  to an Intel box.

  Sometime down the road, they will (hopefully!) be switching to an Alpha
  based WNT system.

  Can they 'just' disconnect the Intel system and connect the Alpha system
  and use the underlying storage?  Yes, the .EXEs (DLLs, applications, etc.)
  would be different... but I'm really referring to the data files
  (shares, etc) that are served out to the user community.

  Or, is there a difference in the way that Intel vs. Alpha actually stores
  the blocks out on the disks.  I seem to remember that there is something
  different between Alpha/Intel re: disk storage -- that's why we can't have
  mixed (Alpha/Intel) WNT Clusters today.

  Cross posted to HSZ40_PRODUCT  &  WINDOWS-NT.
T.RTitleUserPersonal
Name		DateLines
5885.1FAT yes, NTFS noRTOMS::dhcp-203-80-56.suo.dec.com::WagenblastThis brain intentionally left blankTue Apr 08 1997 00:5215
For FAT filesystems, it will work.

For NTFS filesystems, it won't work.

Reason: NTFS is a log based filesystem. Microsoft messed up compatibility 
of NTFS between Intel and Alpha, by using a different record size for the 
NTFS log file. So if you move an NTFS file system between Intel and Alpha, 
the other OS will not be able to read the NTFS log file, and thus won't be 
able to recognize the file system.

When moving the disks between the two OSes you have to reformat any NTFS 
partition. But this should be not that big an issue, just will cost you 
some time for the backup/restore.
5885.2COOKIE::FROEHLINVMS...riding into the setting sun!Tue Apr 08 1997 13:1010
.1>Reason: NTFS is a log based filesystem. Microsoft messed up compatibility 
    
    Really? Isn't that a bit loose use of the term "log based"?
    
    From "Windows NT File Systems" by Helen Custer:
    
    p.11 "...NTFS is a sophisticated relational database that incorporates
    the latest technical advances in data logging..."
    
    Guenther
5885.3MOVIES::WIDDOWSONRod OpenVMS Engineering. Project RockWed Apr 09 1997 05:093
    Naa, I think the two are compatible.  What is more dubious is the
    assertion that it was the first commercially available Log-based
    filesystem.
5885.4COOKIE::FROEHLINVMS...riding into the setting sun!Wed Apr 09 1997 14:4515
.3> Naa, I think the two are compatible.  What is more dubious is the
    
    Rod, is that "Naa" to the fact that NTFS Alpha and Intel are compatible
    or that NTFS is a log based file system? If the later...
    
    NTFS is described as "...is like the FAT file system in that it uses
    the cluster as its fundamental unit of disk allocation." All file
    blocks on disk are static...once allocated they don't move. The only
    log written is the transaction log. This log, like a database journal,
    "...contains transaction records NTFS write in order to recover a
    volume...".
    
    Anyway...just wanted to point out that NTFS is snow from last year.
    
    Guenther
5885.5MOVIES::WIDDOWSONRod OpenVMS Engineering. Project RockThu Apr 10 1997 04:0614
    Sorry Guenther.  I meant that the two two *statements* are compatible. 
    Alpha and x86 NTFS ODS's aint. (.... sigh ....)
    
    In Log *based* filesystems, the data doesn't move but the metadata is
    logged to avoid either FSCK or the performance penalty of carefull
    writes.   Log based filesystems have been around a while - ADVfs is an
    example in the digital space, but there is also DEC DFS and I think
    that the Veritas filesystem us logged...
    
    Log *structuring* is like log based but without the fixed data bit (all
    data goes into the log). Examples are the Berkly LFS and it's spinoffs,
    and Spiralog..
    
    As to the rest, I concur...
5885.6I think it worked for me once?EPS::VANDENHEUVELHeinWed Apr 16 1997 11:3726
    You folks sure about the mismatch? Is it possible to be 'lucky'?
    I experimented a while ago with an INTEL and ALPHA NT 4.0 system
    each on the same SCSI bus (obviously with one controller modified
    from id=7 to id=0) and managed to 'switch' a device relativly 
    properly between the two systems after having allowed the disk
    adminstrator to have a free go at the drive from both systems. 
    (To switch I deasigned a drive letter on one, assigned on the other,
    is that as close to a 'dismount' command as you can come?).
    
    In a seperate experiment I build a disk on Intel, loaded it with data,
    and stuck it in a slot on the Alpha and (ofcourse) that worked also.
    
    I'm pretty sure that in both case the drives were formatted NTFS
    but it's been a while so I must remember wrong? Is there a low-
    usage / empty state in the metadata log where the incompatibilties
    did not hurt?
    
    I used it to move over a bulk of bcp files because SQLserver binary
    database files are NOT compatible between intel and Alpha. (Even the
    backups are incompatible :-( ).
    
    2�,
    	Hein.
5885.7DECWET::SCHREIBERDECeNTMon Apr 21 1997 18:187
    I believe that if the first system is cleanly shut down you will have
    no problem in moving the disk between architectures.  It's only in the
    case of an unclean shutdown (crash of some sort) that the log file
    sizes become an issue.  Of course, that is one of the more important
    times to have high flexibility in moving disks around.
    
    Benn