NT 4.0 - NTFS vs. OS/2 Warp4 HPFS
Robert L. Howard
I'm a long time OS/2 user (since 2.1), currently using Warp v4.
I use HPFS for all partitions based on the conventional wisom of:
a) HPFS is faster ("high performance")
b) HPFS doesn't suffer from fragmentation
Therefore:
a) Everyone seems to recommend HPFS (plus you get long filenames, etc.)
b) Nobody bothers to make / buy HPFS de-fragmentation programs.
I will soon be using NT 4.0 on this same machine (don't really want to
but must). I am really confused about my filesystem options.
My understanding always was that NT was an outgrowth of HPFS (Microsoft
"created" both). Yet from gleaning NT newsgroups I discover:
a) Most (including MS) recommend FAT as faster
b) The need for and supply of de-fraggers is rampant
What gives? Is NT really that bad? I understand other reasons why I would
want to use NTFS (long names, security, etc.) but what kiknd of performance
hit am I talking about here? Am I really going to step back to the "bad
old days" and start worrying about fragmentation again (I never worry
about it on UNIX either).
So how should I partition / format my drive for NT? Also would be willing
to accept recommendation on making NT / Warp work together in a boot manager
environment so I can use both on the same machine....
Thanks,
Robert
--
| Robert L. Howard | Georgia Tech Research Institute |
| robert...@gtri.gatech.edu | SEAL / ATDD |
| (770) 528-7165 | Atlanta, Georgia 30332 |
-------------------------------------------------------------------------
|"Government subsidies can be critically analyzed according to a simple |
| principle: You are smarter than the government, so when the government|
| pays you to do something you wouldn't do on your own, it is almost |
| always paying you to do something stupid." -- P.J. O'Rourke |
Todd K
Robert L. Howard <rho...@seal.gtri.gatech.edu> wrote in article
<rhoward.849558686@romeo>...
>
> I'm a long time OS/2 user (since 2.1), currently using Warp v4.
>
> I use HPFS for all partitions based on the conventional wisom of:
> a) HPFS is faster ("high performance")
> b) HPFS doesn't suffer from fragmentation
Well, in my experience (a) is correct, although I don't find it
any faster than FAT (as a file system).
I would take exception to point (b) however, as HPFS can definitely
become fragmented, although, not as fast as a FAT file system can,
due to its different design.
>
> Therefore:
> a) Everyone seems to recommend HPFS (plus you get long filenames,
etc.)
When using OS/2, of course, *use* HPFS.
> b) Nobody bothers to make / buy HPFS de-fragmentation programs.
A few of them exists as shareware on Hobbes, I believe.
>
> I will soon be using NT 4.0 on this same machine (don't really want to
> but must). I am really confused about my filesystem options.
NT 4.0 officially doesn't support HPFS anymore (although you can get the
driver from NT 3.51) - MS is really lame in this regard (why would you
drop support for a file system if you already have the driver written?!?)
However, if you are running NT, there really is no better file system than
NTFS. I have used many variations of UNIX (HP-UX and Solaris), and I
prefer
the NTFS file system.
While HPFS is basically a bare-bones file system (with little overhead as
well),
NTFS is quite the opposite in that it gives you quite a few options. For
example,
NTFS supports mirror striping, RAID, directory/file compression (as a file
attribute!),
full security (more powerful than a lot of UNIXes, btw), and a few other
esoteric
functions that a lot of people won't use).
I have never had to defragment an NTFS file system, as I believe it is the
least prone to fragmentation out of the three (HPFS,FAT,NTFS).
With the above features, there is a loss of performance. OS/2 advocates
will peg the figure at 25% overhead, while NT advocates peg the figure
at almost 0% due to NT's superior cacheing algorithm.
I find that it is somewhere in between, and also varies with the kind
of file access that you are doing.
For web servers, I don't perceive any slowdown of the file system (doing
only reads anyways, right?)
>
> My understanding always was that NT was an outgrowth of HPFS (Microsoft
> "created" both). Yet from gleaning NT newsgroups I discover:
> a) Most (including MS) recommend FAT as faster
Well, I think it is common practice to allocate a FAT partition for DOS
(if you play games), or sometimes for the swap file, as you don't need
security (the system always has exclusive access).
> b) The need for and supply of de-fraggers is rampant
No. NTFS doesn't fragment that easily at all. I have *never* had to
run a utility that defrags. NTFS (haven't seen one, actually)
>
> What gives? Is NT really that bad? I understand other reasons why I
would
> want to use NTFS (long names, security, etc.) but what kiknd of
performance
> hit am I talking about here? Am I really going to step back to the "bad
> old days" and start worrying about fragmentation again (I never worry
> about it on UNIX either).
Don't worry. I've never run across the problems above. We've got
literally
hundreds of NT servers, none of which have those problems. (Even our UNIX
systems don't suffer from the above problems :-)
>
> So how should I partition / format my drive for NT? Also would be
willing
> to accept recommendation on making NT / Warp work together in a boot
manager
> environment so I can use both on the same machine....
Well, I would read up on articles that show you how to use HPFS on NT 4.0,
then
you can have three file systems supported. I believe you need to copy a
file
called 'pinball.dll' or something. Anyways, look in the NT.MISC group for
that.
-Todd K.
Keith Medcalf
In <rhoward.849558686@romeo>, rho...@seal.gtri.gatech.edu (Robert L. Howard) writes:
>My understanding always was that NT was an outgrowth of HPFS (Microsoft
NTFS is an outgrowth of FAT, and an adaption of a File System originally
designed to store files on 160k diskettes to large fixed DASD storage
devices. HPFS was designed from the ground up for large DASD devices.
>"created" both). Yet from gleaning NT newsgroups I discover:
> a) Most (including MS) recommend FAT as faster
> b) The need for and supply of de-fraggers is rampant
>What gives? Is NT really that bad? I understand other reasons why I would
>want to use NTFS (long names, security, etc.) but what kiknd of performance
>hit am I talking about here? Am I really going to step back to the "bad
>old days" and start worrying about fragmentation again (I never worry
>about it on UNIX either).
The performance hit depends on your usage and expectations. For NT
server on 100 Mbps ethernet with 4 133 Mhz pentium CPUs and 128 MB RAM,
as a File Server with NTFS, NT can push about 28 megabits from disk out
the ethernet. Switching to FAT will get about 45 megabits.
By way of relative comparison, OS/2 Warp Server 3.0 running on the same
hardware (but with only one cpu) using regular FAT, can push about 14
megabits from disk to ethernet. Using HPFS (baby-HPFS) pushes 35
megabits; and HPFS386, more than 70 megabits.
Windows for Workgroups on equivalent hardware can push 8 megabits, and
Windows 95 can push 14 megabits.
OS/2 Warp Server (Advanced) will be able to maintain the same
performance characteristic when running on a Pentium 100 and reducing
memory to 32 MB. For straight file service and DMA I/O all round, a
486/66 will be sufficient.
As you can see, NT is better than Windows, so for Windows users, NT is
an upgrade. For an OS/2 user, however, NT is quite a downgrade:
somewhat like trading in a Lamborgini for an Armoured Personnel Carrier.
Of course, I could be somewhat biased, however, feel free to read the
LANQuest reports yourself.
-------------------------------------------------------------
Keith Medcalf (416) 410-5791 http://www.dessus.com/
Keith Medcalf & Associates, 152-275 Broadview Avenue, Toronto
IBM OS/2, LAN Server, DB2/2, TCP/IP, DOS, Windows, Windows NT
IBM System Management Software Specialist IBM BESTeam Member
IBM OS/2 Warp Server Software Specialist
Darrell P.
Keith Medcalf <kmed...@dessus.com > wrote in article
<5801qf$5...@news1.io.org>...
>
> <snip>
>
> NTFS is an outgrowth of FAT, and an adaption of a File System originally
> designed to store files on 160k diskettes to large fixed DASD storage
> devices. HPFS was designed from the ground up for large DASD devices.
>
NTFS has no roots in FAT. It was specifically designed to take advantage of
large DASD devices and RAID arrays. As far back as NT 3.1, NTFS has
supported larger volumes/partitions than any implementation of HPFS.
sae...@ibm.net
>
>I use HPFS for all partitions based on the conventional wisom of:
> a) HPFS is faster ("high performance")
> b) HPFS doesn't suffer from fragmentation
Actually, HPFS is very resistant to defragmentation.
>
>Therefore:
> a) Everyone seems to recommend HPFS (plus you get long filenames, etc.)
> b) Nobody bothers to make / buy HPFS de-fragmentation programs.
Download os2utils.zip from Hobbes or Must Have. It contains a defrag program for
HPFS. You should need to use it very often though since HPFS is "very resistant
to defragmentation." I think Mark Kimes (the author of OS2UTILS) may use that
phrase verbatim.
>
>I will soon be using NT 4.0 on this same machine (don't really want to
>but must). I am really confused about my filesystem options.
>
>My understanding always was that NT was an outgrowth of HPFS (Microsoft
>"created" both). Yet from gleaning NT newsgroups I discover:
> a) Most (including MS) recommend FAT as faster
> b) The need for and supply of de-fraggers is rampant
>
>What gives? Is NT really that bad? I understand other reasons why I would
>want to use NTFS (long names, security, etc.) but what kiknd of performance
>hit am I talking about here? Am I really going to step back to the "bad
>old days" and start worrying about fragmentation again (I never worry
>about it on UNIX either).
It really depends on the machine you will be using. If it's a Pentium 133+
with 32-64 MB RAM and a good, fast hard drive, NT's not so bad. I personally
thought that the install was very sweet. Obtaining device drivers for NT4.0 may
be a hassle depending on the device...OS/2 has the same problem.
Application (Office 95) performance seemed very good, but again, it's going to
depend on what programs you attempting to run.
A note on FAT (you may have heard already!): Due to the size of the allocated
clusters on a FAT partition, HD's larger than about 128 MB, HPFS
or NTFS is recommended over FAT due the large amout of wasted space as the
file system can allocate up to 32K clusters. HPFS/NTFS will allocate 4K clusters
for their partitions, respectively, potentially saving mucho drive space (depending)
on the size of the files you are storing.
>
>So how should I partition / format my drive for NT? Also would be willing
>to accept recommendation on making NT / Warp work together in a boot manager
>environment so I can use both on the same machine....
Although, MS says they've dropped support for HPFS drives, you can download the
WinNT3.5 PINBALL.SYS that will allow you to manually add support for HPFS under
NT4.0. I can't remember the site to get the kit, but I've got it at work. Email me
if you are interested.
Personally, with an appropriate machine, I'd do NTFS for NT and HPFS for Warp.
Then I'd apply PINBALL.SYS so you can share data between the two with Dual Boot.
This is what I plan to do here at home. You may want to investigate Partition Magic
and System Commander before doing so.
Again, the answer to your question depends on what you are trying to run and what
you are trying to run it on since NT is not very resource friendly (even on FAT).
Hope this helps some,
Steve
sae...@ibm.net
jim frost
rho...@seal.gtri.gatech.edu (Robert L. Howard) writes:
>My understanding always was that NT was an outgrowth of HPFS (Microsoft
>"created" both). Yet from gleaning NT newsgroups I discover:
> a) Most (including MS) recommend FAT as faster
> b) The need for and supply of de-fraggers is rampant
b) is overstressed. NTFS does get fragmented, but not to the degree
that FAT does. HPFS gets fragmented too, as does UNIX FFS. All three
filesystems attempt to intelligently place fragments such that seek
latency is tolerable, with good success. You will see performance
degredation but it should be well within acceptable bounds.
a) is true in many cases (and false in a few) due to additional
functionality in NTFS. NTFS uses a three-phase commit that makes it a
lot more reliable than either FAT or HPFS (though in practice HPFS is
so reliable that it's tough to tell); it's very similar in design and
performance to AIX's JFS. That slows down writes considerably,
although the asynchronicity in NT's filesystem management makes the
impact largely invisible to your average user. In addition NTFS'
security management requires a bit of disk overhead, another loss. If
properly used, however, it also eliminates viruses. Lastly, NTFS
directories are B-tree organized (as are HPFS directories) so if you
have a large directory listing -- eg the NT OS directory -- NTFS
outperforms FAT hands down.
In short you win some and you lose some with NTFS. Personally I like
the features and don't notice the performance loss, so it's a winning
situation.
>Am I really going to step back to the "bad
>old days" and start worrying about fragmentation again (I never worry
>about it on UNIX either).
Nope. NTFS doesn't avoid fragmentation as well as does FFS (neither
does HPFS, for the same reasons) but neither does it degrade to the
point of uselessness like FAT.
>So how should I partition / format my drive for NT? Also would be willing
>to accept recommendation on making NT / Warp work together in a boot manager
>environment so I can use both on the same machine....
The only supported way to get NT to read the same partitions as Warp
is to use FAT. I personally boot several OS's on my machine and use
a 0.5GB FAT partition as a least-common-denominator filesystem for
moving large things between them (and for Win95), and run native
filesystems as much as possible for best features and performance of
the native system.
jim frost
ji...@world.std.com
--
http://world.std.com/~jimf
Thomas G. McWilliams
Robert L. Howard (rho...@seal.gtri.gatech.edu) wrote:
: What gives? Is NT really that bad? I understand other reasons why I would
: want to use NTFS (long names, security, etc.) but what kiknd of performance
: old days" and start worrying about fragmentation again (I never worry
NTFS is subject to fragmentation problems, also NTFS is dog slow
compared to the nimble HPFS. You would probably be better off using
FAT under NT. Actually, you would probably be better off avoiding NT
altogether if file system performance is a consideration.
Dave Cinege
In <01bbe0bd$ad8d4ce0$bc900c0f@tksnet>, "Todd K" <todd_...@hp-singapore-notes1.om.hp.com> writes:
>example,
>NTFS supports mirror striping, RAID, directory/file compression (as a file
>attribute!),
Hold on there, no filesystem supports RAID or anything like that. It is a
disk opperation not a file system operation. NT may include software RAID
support but that has nothing to do with the fs. I run a DPT with 4 drives
striped, and I have DOS, OS/2, and Linux using FAT, HPFS, and ext2 all on
the same RAID.
>full security (more powerful than a lot of UNIXes, btw), and a few other
>esoteric
>functions that a lot of people won't use).
>
>I have never had to defragment an NTFS file system, as I believe it is the
>least prone to fragmentation out of the three (HPFS,FAT,NTFS).
>
>With the above features, there is a loss of performance. OS/2 advocates
>will peg the figure at 25% overhead, while NT advocates peg the figure
>at almost 0% due to NT's superior cacheing algorithm.
This is the case with ALL software based disk access schemes.
----------------------------------------------------------------------------
Dave 'Kill a Cop' Cinege (aka Psychopath #3) --- Super Genius at Large
Wanna see Bill Gate's idea of Plug & Play? Bend over....
http://www.psychosis.com/
Libertarian Party 1-800-682-1776 http://www.lp.org/
jim frost
kmed...@dessus.com (Keith Medcalf) writes:
>In <rhoward.849558686@romeo>, rho...@seal.gtri.gatech.edu (Robert L. Howard) writes:
>>My understanding always was that NT was an outgrowth of HPFS (Microsoft
>NTFS is an outgrowth of FAT, and an adaption of a File System originally
>designed to store files on 160k diskettes to large fixed DASD storage
>devices. HPFS was designed from the ground up for large DASD devices.
I don't know where you got this stuff, but aside from the FAT
origination it's totally wrong.
HPFS is a close derivative to BSD FFS, the filesystem used in most
UNIX variants today. They stripped out the security features, did
some work on the file table (inode) management, use B-tree rather than
linear lists for directories, and simplified block allocation
management (no rotational optimization, simpler cylinder optimization)
but the basic organization is the same.
NTFS is a derivative of HPFS using three-phase commit rather than
synchronous meta-filesystem writes to protect filesystem integrity and
supplying both security features and multiple data streams.
I have no idea where you got the idea that NTFS was related to FAT in
some way. They're totally different in every single respect.
Todd K
Dave Cinege <dci...@fuckthejunkmailers.org> wrote in article
<5807cn$5...@earth.superlink.net>...
> In <01bbe0bd$ad8d4ce0$bc900c0f@tksnet>, "Todd K"
<todd_...@hp-singapore-notes1.om.hp.com> writes:
>
> >example,
> >NTFS supports mirror striping, RAID, directory/file compression (as a
file
> >attribute!),
>
> Hold on there, no filesystem supports RAID or anything like that. It is a
> disk opperation not a file system operation. NT may include software RAID
> support but that has nothing to do with the fs. I run a DPT with 4 drives
> striped, and I have DOS, OS/2, and Linux using FAT, HPFS, and ext2 all on
> the same RAID.
Whoops. Yup, you're right. I should have said that NT has built-in
support
for that instead of NTFS. It's just that NT does such a good job of
intergrating all this...
-Todd K.
Todd K
Thomas G. McWilliams <t...@netcom.com> wrote in article
<tgmE1t...@netcom.com>...
FUD.
If you had read Jim Frost's explanation (very good IMO), you would see
that you are plain wrong.
You obviously don't have a clue to what you are talking about.
Stop the FUD.
-Todd K.
>
>
Chris Hanson
From: "Todd K" <todd_...@hp-singapore-notes1.om.hp.com>
Date: Tue, 3 Dec 1996 01:59:20 GMT
Robert L. Howard <rho...@seal.gtri.gatech.edu> wrote in article
<rhoward.849558686@romeo>...
> b) Nobody bothers to make / buy HPFS de-fragmentation programs.
A few of them exists as shareware on Hobbes, I believe.
Also, GammaTech Utilities has a reasonable de-fragger.
> b) The need for and supply of de-fraggers is rampant
No. NTFS doesn't fragment that easily at all. I have *never* had
to run a utility that defrags. NTFS (haven't seen one, actually)
I recently installed NT 4.0 on my machine, and got DiskKeeper Lite
(freeware) for it, as recommended by a friend who uses NT alot. After
installing about 20 apps, I ran DiskKeeper and found that my disk was
quite badly fragmented; DiskKeeper did its thing and now the disk has
very little fragmentation.
> So how should I partition / format my drive for NT? Also would
> be willing to accept recommendation on making NT / Warp work
> together in a boot manager environment so I can use both on the
> same machine....
Well, I would read up on articles that show you how to use HPFS on
NT 4.0, then you can have three file systems supported. I believe
you need to copy a file called 'pinball.dll' or something.
Anyways, look in the NT.MISC group for that.
See "http://www.students.uiuc.edu/~kwilas/useful.html" for detailed
instructions.
Jeremy Mathers
In article <01bbe0e5$51b3efa0$bc900c0f@tksnet>,
Todd K <todd_...@hp-singapore-notes1.om.hp.com> wrote:
...
>FUD.
>
>If you had read Jim Frost's explanation (very good IMO), you would see
>that you are plain wrong.
>
>You obviously don't have a clue to what you are talking about.
>
>Stop the FUD.
I am always amused when I see an NT/Microsofter crying FUD.
One has visions of Albert Belle decrying the lack of civility in modern life.
Or, to put it most succinctly, let's just accept the fact that Microsoft has
the marketing superiority (by a mile or so) and that IBM has the superior
technology (always had and always will). But it offends me when I see
either side claim to have that which the other side clearly owns.
************************************************************************
"At Tower Books in Bellevue, Helen Custer's _Inside_Windows_NT_ is
outselling Madonna's _Sex_ by 125 to 109."
-- Seattle Times, Jan 21, 1993
- py...@quads.uchicago.edu, who is still costing the net
hundreds, if not thousands, of dollars, every time he posts -
************************************************************************
rwvpf wpnrrj ibf ijrfer
Darwin Ouyang
In article <rhoward.849558686@romeo>,
Robert L. Howard <rho...@seal.gtri.gatech.edu> wrote:
>What gives? Is NT really that bad? I understand other reasons why I would
>want to use NTFS (long names, security, etc.) but what kiknd of performance
>hit am I talking about here? Am I really going to step back to the "bad
>old days" and start worrying about fragmentation again (I never worry
>about it on UNIX either).
I'm very unhappy with NTFS at this point in time.
My 850 MB NTFS partition has a master file table that is fragmented into
about 400 pieces. This is really slowing down file system access. The
worst part of this is that the MFT cannot be optimized by *any* NTFS
defragmenter out there right now.
Since my MFT is fragmented into so many pieces, the contagious free
blocks on my HD are tiny. So, for example, I have a win32 API reference
file (20 MB) that is fragmented into over 1000 pieces, simply because
there aren't enough large contigious blocks to write out the file.
The simple result of this is to fix the problem, I'm going to have to find
a tape backup unit, backup, FORMAT, and restore.
Another interesting thing that I discovered while reading the
documentation for Norton Speedisk for NT (beta), is that NTFS will not use
free space blocks of less then 16 sectors, even though the minimum
allocation unit (like HPFS) is one sector. Thus any free block of less
then 16 sectors is essentially wasted space - which makes free space
consolidation a BIG factor with NTFS.
My drive used to have over 20,000 file fragments and over 10,000 free
space fragments. After using Norton Speedisk for NT (beta), I still have
over 1,000 file fragments and 2,000 free space fragments.
It still takes several minutes to do a drive search.
This sucks.
Darwin Ouyang
Kevin Krieser
> Therefore:
> a) Everyone seems to recommend HPFS (plus you get long filenames, etc.)
>
> but must). I am really confused about my filesystem options.
>
> a) Most (including MS) recommend FAT as faster
defragmenter.
Anyway, I doubt that NTFS is any more prone to fragmentation than HPFS. And both, though
designed to fragment less easily, can be fragmented if you have software that does a lot of
appends.
And while HPFS has tended to be faster than NTFS (when tested in a more equal environment, such
as both under NT 3.51), NTFS has other advantages like greater speed of repair after unorderly
shutdown.
I've noticed that, compared to FAT, NTFS can be 1/2 the speed. It depends on what you do, your
mix of writes/reads, of the speed comparison. Also, if you have enough disk drives, you can
make up some of the speed by stripping your disk drives.
Note. Even with the speed loss, on the computer I run NT, I have all but the boot disk in a
striped NTFS set. My OS/2 disk is all HPFS.
------------------------------------
-- Kevin Krieser
-- kkri...@ionet.net
Christopher W. Curtis
In <rhoward.849558686@romeo> rho...@seal.gtri.gatech.edu (Robert L. Howard) writes:
>My understanding always was that NT was an outgrowth of HPFS (Microsoft
>"created" both). Yet from gleaning NT newsgroups I discover:
> a) Most (including MS) recommend FAT as faster
> b) The need for and supply of de-fraggers is rampant
I wouldn't say that MS "created" both, but it is true that NTFS is a
derivative of HPFS. However, somewhere in the mix, it became apparent
that "HP" (high-performance) had to be removed from NTFS. I honestly
do not know why; neither security nor journaling slow down UNIX boxes
to the same proportion that they seem to do NT. But I do not under-
stand wholly why they would recommend FAT over NTFS. My best guess
is because Win95 doesn't support NTFS and NT doesn't support VFAT.
Unless you indent to mix filesystems, I, having no prior experience,
would say to install NT on NTFS, and leave a FAT partition just in
case you want to share files between OS/2 and NT. MS, in their ever-
lovin' wisdom, removed HPFS support from NT in version 4 so things
just can't be easy. With MS, ya gotta pick and choose. To the best
of my knowledge, this 'slowdown' is only prevalent when used as a
file or print server (and in which case I have to wonder why OS/2
wasn't used instead) on a 100 Mbps network.
>What gives? Is NT really that bad? I understand other reasons why I would
>want to use NTFS (long names, security, etc.) but what kiknd of performance
>hit am I talking about here? Am I really going to step back to the "bad
>old days" and start worrying about fragmentation again (I never worry
>about it on UNIX either).
I suspect not. However, YMMV.
>So how should I partition / format my drive for NT? Also would be willing
>to accept recommendation on making NT / Warp work together in a boot manager
>environment so I can use both on the same machine....
There is a more appropriate place to ask this: os2.setup maybe? I
tried once to BM OS/2 and NT, but when NT 'fdisk'd the drive, it
screwed things up royally and we were never able to get it to work.
And NT refused to boot OS/2 through its boot loader, so no OS/2. :(
--
Christopher Curtis, SysAdmin - http://www.ee.fit.edu/users/ccurtis/
Florida Institute of Technology - Team OS/2 [Fanatics Division]
Melbourne, Florida USA - http://www.lp.org/
Sangria
On 3 Dec 1996 02:03:59 GMT, kmed...@dessus.com (Keith Medcalf)
wrote:
>In <rhoward.849558686@romeo>, rho...@seal.gtri.gatech.edu (Robert L. Howard) writes:
>
>>My understanding always was that NT was an outgrowth of HPFS (Microsoft
>
>NTFS is an outgrowth of FAT, and an adaption of a File System originally
>designed to store files on 160k diskettes to large fixed DASD storage
>devices. HPFS was designed from the ground up for large DASD devices.
Your information is seriously flawed.
NTFS is not an outgrowth of FAT. If anything, it would be more
accurate to describe NTFS to be a grounds up redesign of a file
system.
-- Sang.
********************************************************
* Sang K. Choe san...@inlink.com *
* http://sangria.inlink.com/index.html *
* finger: sa...@sangria.inlink.com *
********************************************************
Todd K
Jeremy Mathers <py...@midway.uchicago.edu> wrote in article
<E1uD9...@midway.uchicago.edu>...
> In article <01bbe0e5$51b3efa0$bc900c0f@tksnet>,
> Todd K <todd_...@hp-singapore-notes1.om.hp.com> wrote:
> ...
> >FUD.
> >
> >If you had read Jim Frost's explanation (very good IMO), you would see
> >that you are plain wrong.
> >
> >You obviously don't have a clue to what you are talking about.
> >
> >Stop the FUD.
>
> I am always amused when I see an NT/Microsofter crying FUD.
>
> One has visions of Albert Belle decrying the lack of civility in modern
life.
>
> Or, to put it most succinctly, let's just accept the fact that Microsoft
has
> the marketing superiority (by a mile or so) and that IBM has the superior
> technology (always had and always will). But it offends me when I see
> either side claim to have that which the other side clearly owns.
HPFS superior to NTFS?
NT's multiple input queues vs. OS/2's single input queue?
NT's dynamic cacheing vs. OS/2's static?
NT's support for RAID/Mirroring vs. nothing for OS/2?
NT's excellent memory protection vs. OS/2's shared dll's in memory?
.
.
.
hmmm... superior technology from IBM... think I'll keep my primitive
NT system.
-Todd K.
cro...@kuentos.guam.net
In <32a5f648.182693250@snoopy>, san...@inlink.com (Sangria) writes:
>On 3 Dec 1996 02:03:59 GMT, kmed...@dessus.com (Keith Medcalf)
>wrote:
>
>>In <rhoward.849558686@romeo>, rho...@seal.gtri.gatech.edu (Robert L. Howard) writes:
>>
>>>My understanding always was that NT was an outgrowth of HPFS (Microsoft
>>
>>NTFS is an outgrowth of FAT, and an adaption of a File System originally
>>designed to store files on 160k diskettes to large fixed DASD storage
>>devices. HPFS was designed from the ground up for large DASD devices.
>
>Your information is seriously flawed.
>NTFS is not an outgrowth of FAT. If anything, it would be more
>accurate to describe NTFS to be a grounds up redesign of a file
>system.
>
Being a grounds up redesign is not what Mr. Jim
Frost just described about NTFS.
Rgds,
Chris
Famous People on Operating Systems (Please feel free to contribute)
Edgar Allen Poe, writing a poem when his PC crashed---
"Microsoft, nevermore, nevermore."
President Roosevelt, during the day Windows 95 is launched---
"This day shall live in infamy."
Thanks to those who contributed. ***cro...@kuentos.guam.net***
ls0916
Hi Robert,
I've been using OS/2 for a couple of years, and also switched over to NT
in the past year. I dual boot with OS/2 and NT on the same machine. I started
out with 3.51 but am presently using 4.0.
Probably the best thing that NTFS has to offer over HPFS is that if the computer
crashes, or if you turn it off suddenly, etc, you won't have to wait for a CHKDSK at start up.
NTFS is "recoverable", which means that it keeps a log of all the changes it makes,
unlike HPFS which keeps no such log. If you unexpectedly turn off an OS/2 machine,
on start up it detects that the disk is "dirty" and goes through a chkdsk of the whole
disk. If you have a couple of gigs, then this could be pretty annoying.
Under NT, instead of doing a whole chkdsk, it goes through it's transaction log of
all disk writes, and makes sure that they were all completed, and backs out of any
that weren't. This takes a few (1-2) seconds.
Other than that, I really haven't been noticing any differences between HPFS, NTFS,
or FAT, realistically. I really don't think performance is much of an issue if all
you're going to be using the drives for is your own personal use. I'm sure if you're
trying to squeeze milliseconds for your server, or for benchmarking, I can understand
the concern, but personally, I don't see ANY performance differences (VC++ compiling,
Netscape, etc.)
Another tip is that 4.0 is going to give you a log of grief when you try to install
NT on an OS/2 machine. First of all, it doesn't recognize HPFS, and it's going to
tell you that. But as a couple of people in this thread said, you can configure
4.0 to recognize it. However, from my experience, you will have to make sure that
you're C: is FAT, otherwise you won't be able to install NT. This took me the longest
time to figure out. It doesn't explicitly say this, only that I couldn't install with
OS/2 on it.
I'm not sure how your computer is set up right now, but if you're openminded to a
fresh install of both OS's,
1) install OS/2 on C: as FAT and NT afterwards (I hate using OS/2 on FAT, though)
2) install DOS (or WIN 95) on C:, OS/2 on an HPFS partition, and then NT.
You won't need to use Boot manager, unless you want to set up a separate primary
partition for any of the OS's. NT has it's own "Boot Manager".
Steve
Robert L. Howard wrote:
[snip]
> Therefore:
> a) Everyone seems to recommend HPFS (plus you get long filenames, etc.)
> b) Nobody bothers to make / buy HPFS de-fragmentation programs.
>
> I will soon be using NT 4.0 on this same machine (don't really want to
> but must). I am really confused about my filesystem options.
>
> My understanding always was that NT was an outgrowth of HPFS (Microsoft
> "created" both). Yet from gleaning NT newsgroups I discover:
> a) Most (including MS) recommend FAT as faster
> b) The need for and supply of de-fraggers is rampant
>
> What gives? Is NT really that bad? I understand other reasons why I would
> want to use NTFS (long names, security, etc.) but what kiknd of performance
> hit am I talking about here? Am I really going to step back to the "bad
> old days" and start worrying about fragmentation again (I never worry
> about it on UNIX either).
>
> So how should I partition / format my drive for NT? Also would be willing
> to accept recommendation on making NT / Warp work together in a boot manager
> environment so I can use both on the same machine....
>
vjniemey@ionet.net@ionet.net
In <ccurtis....@ee.fit.edu>, ccu...@ee.fit.edu (Christopher W. Curtis) writes:
>In <rhoward.849558686@romeo> rho...@seal.gtri.gatech.edu (Robert L. Howard) writes:
>
>>My understanding always was that NT was an outgrowth of HPFS (Microsoft
>>"created" both). Yet from gleaning NT newsgroups I discover:
>> a) Most (including MS) recommend FAT as faster
>> b) The need for and supply of de-fraggers is rampant
>
>derivative of HPFS. However, somewhere in the mix, it became apparent
>that "HP" (high-performance) had to be removed from NTFS. I honestly
>do not know why; neither security nor journaling slow down UNIX boxes
>to the same proportion that they seem to do NT. But I do not under-
>stand wholly why they would recommend FAT over NTFS. My best guess
>is because Win95 doesn't support NTFS and NT doesn't support VFAT.
>Unless you indent to mix filesystems, I, having no prior experience,
>would say to install NT on NTFS, and leave a FAT partition just in
>case you want to share files between OS/2 and NT. MS, in their ever-
>lovin' wisdom, removed HPFS support from NT in version 4 so things
>just can't be easy. With MS, ya gotta pick and choose. To the best
>of my knowledge, this 'slowdown' is only prevalent when used as a
>file or print server (and in which case I have to wonder why OS/2
>wasn't used instead) on a 100 Mbps network.
>
>>want to use NTFS (long names, security, etc.) but what kiknd of performance
>>hit am I talking about here? Am I really going to step back to the "bad
>>old days" and start worrying about fragmentation again (I never worry
>>about it on UNIX either).
>
>
>>to accept recommendation on making NT / Warp work together in a boot manager
>>environment so I can use both on the same machine....
>
>tried once to BM OS/2 and NT, but when NT 'fdisk'd the drive, it
>screwed things up royally and we were never able to get it to work.
>And NT refused to boot OS/2 through its boot loader, so no OS/2. :(
>
>--
>Christopher Curtis, SysAdmin - http://www.ee.fit.edu/users/ccurtis/
>Florida Institute of Technology - Team OS/2 [Fanatics Division]
>Melbourne, Florida USA - http://www.lp.org/
I have both warp 4 and NT4 on my computer. Microsoft says in the book, NTFS
is slower than FAT, use it for security.
I tried it but os/2 could not read NTFS! I use HPFS in os/2 and it's my understanding
the os/2 is faster under HPFS!
V.J. Team os/2
Kris Kwilas
In <ccurtis....@ee.fit.edu>, ccu...@ee.fit.edu (Christopher W. Curtis) writes:
>is because Win95 doesn't support NTFS and NT doesn't support VFAT.
Just a small correction: Windows NT does support VFAT(has
since at least 3.51, if memory serves). However, Windows NT
does not currently support the FAT32 filesystem that is
a part of the OSR2 Windows 95 preloads.
Kris
------------------------------------------------------------
Kris Kwilas
kwi...@uiuc.edu www.students.uiuc.edu/~kwilas/
------------------------------------------------------------
Brought to you by the letters O and S, and the number 2.
Jeremy Mathers
In article <32A531...@netcom.ca>, ls0916 <ls0...@netcom.ca> wrote:
>I've been using OS/2 for a couple of years, and also switched over to
>NT in the past year. I dual boot with OS/2 and NT on the same machine.
>I started out with 3.51 but am presently using 4.0.
>
>Probably the best thing that NTFS has to offer over HPFS is that if the
>computer crashes, or if you turn it off suddenly, etc, you won't have
>to wait for a CHKDSK at start up. NTFS is "recoverable", which means
>that it keeps a log of all the changes it makes, unlike HPFS which
>keeps no such log. If you unexpectedly turn off an OS/2 machine, on
>start up it detects that the disk is "dirty" and goes through a chkdsk
>of the whole disk. If you have a couple of gigs, then this could be
>pretty annoying.
Well, I think this *is* the crux of it. NT advocates like to point to the
advantages of journaling and security and whatever else that NTFS provides -
and make no mistake, these features are nifty, and may save your butt
someday - but are then strangely silent when the topic turns to performance.
The TAANSTAAFL rules applies here. And, yes, accordingly to all reports,
including many in the otherwise MS-friendly press, Warp/HPFS performance
runs circles around NT/NTFS, particularly in hard-working, server-type
situations. You pays your money; you takes your chances.
All of life is a tradeoff between speed and accuracy/safety.
That doesn't change.
>Under NT, instead of doing a whole chkdsk, it goes through it's
>transaction log of all disk writes, and makes sure that they were all
>completed, and backs out of any that weren't. This takes a few (1-2)
>seconds.
>
>Other than that, I really haven't been noticing any differences between
>HPFS, NTFS, or FAT, realistically. I really don't think performance is
>much of an issue if all you're going to be using the drives for is your
>own personal use. I'm sure if you're trying to squeeze milliseconds
>for your server, or for benchmarking, I can understand the concern, but
>personally, I don't see ANY performance differences (VC++ compiling,
>Netscape, etc.)
This is probably all true - which indicates that NT is well-positioned as a
consumer OS - oriented towards the novice/home user, for whom safety should
be priority #1. It sounds like for the kind of light use you describe, NTFS
is perfect for you.
************************************************************************
Mathematicians have announced the existence of a new whole number which
lies between 27 and 28. "We don't know why it's there or what it
does," says Cambridge mathematician, Dr. Hilliard Haliard, "we only
know that it doesn't behave properly when put into equations, and that
it is divisible by six, though only once."
- On_The_Hour -
Robert McDermid
In message <01bbe19f$e8b53520$bc900c0f@tksnet> - "Todd K"
<todd_...@hp-singapore-notes1.om.hp.com>Wed, 4 Dec 1996 04:58:53 GMT writes:
>HPFS superior to NTFS?
I would call these roughly equivalent - they have a few different strengths,
but I might be willing to give NTFS a marginal (and insignifigant) win
here.
>NT's multiple input queues vs. OS/2's single input queue?
Again, both of these have plusses and minuses - it's a design decision,
pure and simple, not superior or inferior technology. Also, you got
it wrong, it's NT's asynchronous input queues vs OS/2's synchronous
input queues - both systems have multiple queue's. And there are plenty
of problems associated with having an asynchronous queue too.
>NT's dynamic cacheing vs. OS/2's static?
It's very debatable as to whether that dynamic cache is any advantage
(except in poorly written benchmarks). From what I understand, NT's
dynamic cache still has a lot of problems with sucking memory away
from other apps, and it is doubtful that it offers much performance
benefit in any situation except one where you have far more RAM than
you actually need for your apps. It is highly doubtful that the benefit
it offers is worth the cost of that extra RAM.
>NT's support for RAID/Mirroring vs. nothing for OS/2?
Won't comment on this except to say in a recent comparison in PC-Week
they said that both OSs require third party support for RAID and mirroring.
I don't think what NT has built in is particularly useful.
>NT's excellent memory protection vs. OS/2's shared dll's in memory?
Excuse me? NT and OS/2 have exactly the same memory protection, particularly
for dlls. The only exception is that OS/2 optionally allows DOS
programs some additional hardware access, which is why it's backwards
compatibility is so much superior to NT's. This can be disabled if you
want, so I'd say in this area, OS/2 beats NT hands down, at least in
terms of flexibility.
Let's see what else we have
SOM/DSOM vs COM and the Not Here Yet DCOM
WPS vs that Explorer thing (ugh)
Opendoc vs OLE (double ugh)
Built-in Java vs add-on (soon to be proprietary Windows-specific version)
Rexx scripting language vs no scripting language
Frankly, I find OS/2 and NT to be roughly equivalent technology-wise.
Neither one of them has much that could honestly be called "new technology"
in them. For me, the main advantage of OS/2 is a greatly superior
user-interface, and a much cleaner API - Win32 has too many holdovers
from the slapped together Win16 API, whereas the OS/2 APIs were clearly
carefully designed, and all pretty consistent with one another. It makes
coding for OS/2 an altogether more pleasant experience. Most of the
other advantages come from not having to deal with Microsoft and their
concept of dominating the market through proprietary technologies, rather
than technical excellence. NT was probably the sole exception to this
policy, in that it had a few efforts towards openness in them, but you can
expect to see Microsoft working hard to eliminate these as well.
-- Rob
==============================================================
Rob McDermid Hummingbird Communications Ltd.
mcde...@hcl.com All opinions expressed are my own.
==============================================================
jim frost
cro...@kuentos.guam.net writes:
>>Your information is seriously flawed.
>>NTFS is not an outgrowth of FAT. If anything, it would be more
>>accurate to describe NTFS to be a grounds up redesign of a file
>>system.
>Being a grounds up redesign is not what Mr. Jim
>Frost just described about NTFS.
Right. It was most certainly not a ground-up redesign; it is a strong
derivative of HPFS. Both HPFS and NTFS borrowed heavily from existing
filesystems -- HPFS is structurally very similar to BSD FFS, and NTFS
extends HPFS with a number of filesystem metadata enhancements that
have been available in other filesystems for years. The only thing
that might be considered to be cutting-edge is the update commit
technique which, although long used in databases, was practically
unheard of in filesystems while NT was being developed. Even so, AIX
JFS beat it to market by three years.
krob...@inforamp.net
In <5801qf$5...@news1.io.org>, kmed...@dessus.com (Keith Medcalf) writes:
>Of course, I could be somewhat biased, however, feel free to read the
>LANQuest reports yourself.
>
Anybody got hard data or opinions about HPFS performance under NT?
Caching issues?
Best Regards,
Keith Medcalf
In <5804gc$nck$1...@news-s01.ca.us.ibm.net>, sae...@ibm.net writes:
>In <rhoward.849558686@romeo>, rho...@seal.gtri.gatech.edu (Robert L. Howard) writes:
>>Therefore:
>> a) Everyone seems to recommend HPFS (plus you get long filenames, etc.)
>> b) Nobody bothers to make / buy HPFS de-fragmentation programs.
>Download os2utils.zip from Hobbes or Must Have. It contains a defrag program for
>HPFS. You should need to use it very often though since HPFS is "very resistant
>to defragmentation." I think Mark Kimes (the author of OS2UTILS) may use that
>phrase verbatim.
Don't you mean should'nt need to use it very often? One of the worst
things you can do to an OS/2 system is to "defragment" the filesystem in
the DOS style of making each file contiguous, especially if you do many
disk intensive tasks in parallel or are running as a file server.
Most files will not be able to be defragmented below 2 extents anyway,
and the number of extents does not necessarily have any impact on the
speed of access to the hard drive.
All that you need to do to defragment a file on HPFS, copy it. Most
(all, actually) defragmenters for OS/2 (and all other multitasking
operating systems with decent filesystems) are defragmented this way.
This is because when a file is created and the correct file-size
information is communicated to the Operating System at Create time, the
filesystem will calculate the optimal placement for the data and size of
the extents.
Of course, fragmentation of the free space will occur, however, the
"zoning" of HPFS tends to mitigate this somewhat by ensuring that free
space extents are spread and managed over the entire volume of the
storage device (unlike DOS and NTFS which use very simple space
allocation algorithms -- DOS is so simple it is even reproduceable in
hindsite -- witness all the DOS file recovery tools).
>A note on FAT (you may have heard already!): Due to the size of the allocated
>clusters on a FAT partition, HD's larger than about 128 MB, HPFS
>or NTFS is recommended over FAT due the large amout of wasted space as the
>file system can allocate up to 32K clusters. HPFS/NTFS will allocate 4K clusters
>for their partitions, respectively, potentially saving mucho drive space (depending)
>on the size of the files you are storing.
Sorry, FAT and NTFS use cluster sizes based on the size of the
partition. HPFS does not use "clusters", as all space is allocated
using a sector-based extent allocation algorithm that is closer in its
design to VSAM than it is to the FAT or NTFS methods of space
allocation.
In all cases, "average slack" for an HPFS partition will be somewhat
more than 1/2 sector (256 bytes) and less than one track (varies
depending on disk geometry and translation).
Keith Medcalf
In <01bbe19f$e8b53520$bc900c0f@tksnet>, "Todd K" <todd_...@hp-singapore-notes1.om.hp.com> writes:
>HPFS superior to NTFS?
Very definitely.
>NT's multiple input queues vs. OS/2's single input queue?
Like all GUI programs, every OS/2 PM process has its very own input
queue, as does every NT process. Many OS/2 PM programs have a separate
input queue to service each window running pre-emptively on its own
thread, so each OS/2 PM application can have, effectively, as many input
queues as it has PM widgets displayed on the screen (ie, each text
field, scroll box, border, title bar, menu item, etc can have its very
own input queue, which can even be serviced by its very own
pre-emptively dispatched thread -- if you really wanted to go to this
depth of pluralism).
You are committing the prevalent error of confusing syncronicity with
pluralism; they are not the same thing, and they are completely
independant considerations in the design of the very necessary single
system message/input queue inherent in the design of event-driven
interfaces. Every single event-driven GUI has one, and only one, system
message/input queue, for it cannot be otherwise.
All event-driven interfaces have a single system dispatch queue. The
difference is whether that queue is dispatched to the application queues
in a syncronous fashion, or if it is dispatched asyncronously.
NT dispatches system messages asyncronously at all times. OS/2
dispatches messages syncronously at all times*. Windows also uses the
synchronous dispatching method (it can do no other because it cannot
pre-emptively multitask, so dispatching must occur synchronously since
there is only a single thread of execution.) Windows 95 uses
an asynchronous dispatching, however, this becomes effectively
synchronous whenever it would be useful to be asynchronous due to the
design of the 32-bit supersystem resting on top of the non-reentrant
16-bit windows kernel.
*Note: This is not technically correct. In certain circumstances even
NT will process the system queue syncronously, for example, when
all the messages in the queue are destined for the same
application queue. This circumstance, however, makes your
entire argument degenrate into triviality, so it is ignored. It
should, however, be noted.
OS/2, while it does not do asynchronous dispatching in the
normal course, does have the facility to recognize
non-dispatchable application queues -- a "dead-letter office" so
to speak, for undeliverable messages. Because this is a
work-around for bad-programming-practices (and not to solve any
problem inherent in the design of the PM messaging subsystem
itself, it does not always work in a manner similar to true
asynchronous dispatching, hence some ill-informed people refer
to it is a fault rather than the inherent design feature it is).
(more complicated applications can often require syncronous
message processing, and although it can be emulated/forced on
an asynchronous model such as NT, it greatly complicates the
design of such an application ).
You are making a confusion out of elementary and integral design
decisions that have a profound impact on the design of applications for
these platforms. You can compare the two methods of system queue
dispatching with the lower layer protocols of the TCP/IP protocol stack.
OS/2 works akin to properly windowed TCP connections: data presention
(messages) to the application are delivered complete and in-order. When
awaiting a missing piece of the package and the buffers get full, motion
stops until the errant data finds its way into the correct position.
NT, on the other hand, does not guarantee the order of the delivery of
messages to and between applications -- it uses "reliable UDP", so to
speak, and the application must take extra efforts to ensure that
messages arrive, are dispatched, and processed, in-order if required.
>NT's dynamic cacheing vs. OS/2's static?
Static cache sizing is far more efficient than dynamic sizing in many
cases (Unless the system knows an awful lot about the application mix
running on the computer). Determining the correct cache size involves
having knowledge of the system working set and the DASD working set, and
the paterns and interactions of the two (which is very application
dependant). Quite often, unrestricted dynamic caches make very bad
decisions about whether to allocate memory to the disk cache or the
VM page cache.
No dynamic caching system can make an "automatic" determination of
relative cache allocations which will perform better than a hand-tuned
allocation determined by a proper performance analysis.
Of course, given that the user does not have the wherewithall to make an
appropriate determination, a dynamic cache will generally perform better
than most uninformed users "stab" at making the allocation (unless that
stab is constrained in advance of the user making it).
Generally speaking, dynamic caches are designed for people who either
don't want or cannot tune their systems for optimal performance; while
static caches are designed for people who want high performance.
Note that Unix systems, which have had dynamic cache sizing for a long
time, also benefit from manual tuning (as does NT) by having a
knowledgeable system professional tune the minimum and maximum cache
sizes, as well as other parameters used to make the determination by the
operating system (such parameters as are missing from the NT
implementation is the "Free Page Idle" constraint on conversion of VM
page cache to disk page cache, and other parameters such as sequential
detection thresholds, etc).
In actuality, a properly tuned dynamic sizing cache will outperform a
properly tuned static sized cache over a wider range of conditions;
however, if no tuning whatsoever is done, you are better off with a
fixed size cache than a dynamic one (if you do any actual work on your
computer, that is -- if all you do is type memo's in word, the point is
somewhat moot).
>NT's support for RAID/Mirroring vs. nothing for OS/2?
OS/2 supports software and hardware RAID, fully and completely. You can
get the hardware or software from IBM, or from third-parties.
With NT, only the hardware solution in non-MS. From a performance point
of view, software RAID is usually not an option (ie, software RAID is
generally only used on "toy" computers, not on production systems);
hardware RAID is the only way to go, so both platforms are
equivalent in this regard (though, since more device drivers are
available for OS/2 than for NT, I would think that OS/2 would have
better RAID support than NT. Even from a pure "installed base" figure,
many orders more OS/2 systems are likely to have RAID storage subsystems
than NT systems (actually, their are probably more OS/2 systems with
RAID subsystems than their are NT systems whether with or without RAID))
>NT's excellent memory protection vs. OS/2's shared dll's in memory?
Shared DLLs? The very purpose of putting something in a DLL is so that
it can be shared. Having non-shared DLLs defeats the whole purpose of
using a DLL in the first place!
>hmmm... superior technology from IBM... think I'll keep my primitive
>NT system.
Fine by me. You never get rich by supporting technology that works --
only bu supporting technology which doesn't. The more people use
Windows, Windows 95, and NT; the more money that is to be made
satisfying the insatiable demand for support personnel. There is very
little demand for OS/2 support personnel since it "just works", where
the demand for Win/Win95/NT support is growing at ever increasing rates!
If I want to be sure that a customer stays a customer for a long long
time, I would recommend MS solutions. That assures a relatively long
and profitable relationship (for me) with a relatively steady income
stream from support. OS/2 solutions are one-time things. Put it in and
it works -- and works -- and works (and I don't hear about it again for
months or years).
This, of course, is unethical. Since I know that OS/2 is the better,
more reliable solution, I have to recommend it over NT for most
applications -- even though I know that it is the least profitable for
myself -- it is in the best interests of the client -- and I am required
to act in the best interest of the client. In the end, however, Windows
Magazine seems to prevail and the technology is usurped by the
marketting glossies and "me too" crowd.
Although the wallet is fatter, the heart is saddened ...
Charles Onstott
On Wed, 4 Dec 1996 01:49:49 GMT, ccu...@ee.fit.edu (Christopher W.
Curtis) wrote:
>
>>So how should I partition / format my drive for NT? Also would be willing
>>to accept recommendation on making NT / Warp work together in a boot manager
>>environment so I can use both on the same machine....
>
>There is a more appropriate place to ask this: os2.setup maybe? I
>tried once to BM OS/2 and NT, but when NT 'fdisk'd the drive, it
>screwed things up royally and we were never able to get it to work.
>And NT refused to boot OS/2 through its boot loader, so no OS/2. :(
This probably does belong in an OS/2 group, but the work around
is to simply boot OS/2 from an OS/2 boot floppy and reactivate the
bootmanager with OS/2's FDISK. Once you've done that, you can
go from the OS/2 bootmanager to NT bootloader. I have Win NT 3.51
Server, NT 4.0 Server, NT 4.0 Workstation, Win95, OS/2 Warp Server
3.0, and OS/2 Warp Merlin on the same machine (separate disks) and
am able to boot between them with no problems.
Charles
Charles Onstott
On 4 Dec 1996 15:57:06 GMT, mcde...@hcl.com (Robert McDermid) wrote:
<interesting technical discussion skipped>
>Most of the
>other advantages come from not having to deal with Microsoft and their
>concept of dominating the market through proprietary technologies, rather
>than technical excellence.
Excuse me, but last I heard, OS/2 was made by IBM. You know, IBM,
that 100 billion dollar a year company (some several times larger
than Microsoft), that got there by setting proprietary traps. IBM has
never been an open company technology wise. Anyone who tries to treat
IBM as an underdog is missing the point. IBM's current strategy of
embracing open technology is nothing more than an attempt to return
their customers to the single-source concept they've been tooting
since they started in the computer business. Buy your computers from
us, buy your OS support from us, buy your enterprise management from
us, buy your enterprise messaging system from us, buy this from us,
and that from us, etc, etc. Oh, and by the way, look at the
mainframes were revitalizing and all the Network Computers were
making. Deja vu.
I used OS/2 since v.2.1 until I relealized, with the release of v.4,
IBM wasn't intersted in third party software support for it. It is
rather amazing how outside of a wide variety of shareware, just about
the only stuff that runs on OS/2 is IBM stuff: Lotus desktop
products, Notes, Tivoli TME, VoiceType. (And don't start with the IB
stuff, I get their catalog, and while it looks better than it did a
year ago, it still isn't impressive). Many people accuse IBM of
shoddy marketing. I think its more a failure on those people's part
to really identify IBMs marketing strategy.
Technically you may have some good arguments, but I really don't
understand how otherwise intellegent people accuse Microsoft of
strongarm tactics without realizing that's been IBM's history all
along.
Charles
Graeme Adamson
py...@midway.uchicago.edu (Jeremy Mathers) wrote:
> Well, I think this *is* the crux of it. NT advocates like to point to the
> advantages of journaling and security and whatever else that NTFS provides -
> and make no mistake, these features are nifty, and may save your butt
> someday - but are then strangely silent when the topic turns to performance.
>
> The TAANSTAAFL rules applies here. And, yes, accordingly to all reports,
> including many in the otherwise MS-friendly press, Warp/HPFS performance
> runs circles around NT/NTFS, particularly in hard-working, server-type
> situations. You pays your money; you takes your chances.
I've found NTFS quite adequate for servers, but I don't run workstations
with it (mainly because of 95 dual booting considerations). However, there
is now way I would even consider running a server without full security
capabilities on the filesystem, and that knocks HPFS and FAT out of the
running.
I have found, though, that with a reasonable amount of memory (32MB), NT's
disk performance is amazing with FAT (some benchmarks I've run on the same
machine have shown it to be more than twice as fast as under 95).
Graeme
====================================================
Graeme Adamson of the Clan Mackintosh, INTJ
clay...@spl.co.za, gra...@spl.co.za
- di omnes amant fenestras XCV
Quidquid latine dictum sit, altum videtur.
====================================================
Graeme Adamson
mcde...@hcl.com (Robert McDermid) wrote:
> In message <01bbe19f$e8b53520$bc900c0f@tksnet> - "Todd K"
> <todd_...@hp-singapore-notes1.om.hp.com>Wed, 4 Dec 1996 04:58:53 GMT writes:
>
> >HPFS superior to NTFS?
> I would call these roughly equivalent - they have a few different strengths,
> but I might be willing to give NTFS a marginal (and insignifigant) win
> here.
Unless you need security or file/directory compression, in which case it's
not a marginal win at all.
> >NT's multiple input queues vs. OS/2's single input queue?
> Again, both of these have plusses and minuses - it's a design decision,
> pure and simple, not superior or inferior technology. Also, you got
> it wrong, it's NT's asynchronous input queues vs OS/2's synchronous
> input queues - both systems have multiple queue's. And there are plenty
> of problems associated with having an asynchronous queue too.
Luckily these problems haven't yet made themselves known.
> >NT's dynamic cacheing vs. OS/2's static?
>
> It's very debatable as to whether that dynamic cache is any advantage
> (except in poorly written benchmarks). From what I understand, NT's
> dynamic cache still has a lot of problems with sucking memory away
> from other apps, and it is doubtful that it offers much performance
> benefit in any situation except one where you have far more RAM than
> you actually need for your apps. It is highly doubtful that the benefit
> it offers is worth the cost of that extra RAM.
The benefit is flexibility. If you have an app that does need a lot of
memory (Photoshop for example), it can be given to that app without
compromising your disk performance with a smaller cache for other programs
when the app isn't running.
> >NT's support for RAID/Mirroring vs. nothing for OS/2?
> Won't comment on this except to say in a recent comparison in PC-Week
> they said that both OSs require third party support for RAID and mirroring.
> I don't think what NT has built in is particularly useful.
It works very nicely, thank you.
> >NT's excellent memory protection vs. OS/2's shared dll's in memory?
>
> Excuse me? NT and OS/2 have exactly the same memory protection, particularly
> for dlls. The only exception is that OS/2 optionally allows DOS
> programs some additional hardware access, which is why it's backwards
> compatibility is so much superior to NT's. This can be disabled if you
> want, so I'd say in this area, OS/2 beats NT hands down, at least in
> terms of flexibility.
In PC Magazine earlier this year, NT was rated as being better protected
than OS/2. They created programs designed to crash programs and the OS, and
they couldn't crash NT.
> Let's see what else we have
>
> SOM/DSOM vs COM and the Not Here Yet DCOM
Has it made a difference in anyone's life?
> WPS vs that Explorer thing (ugh)
Explorer vs that WPS thing (ugh)
> Opendoc vs OLE (double ugh)
> Built-in Java vs add-on (soon to be proprietary Windows-specific version)
I see Microsoft have written their first plug-in for Netscape Navigator.
It's a Java VM plug in, which does Java better than Navigator itself does.
> Rexx scripting language vs no scripting language
Rexx and Perl run quite happily on NT (both available with the NT Resource
Kit).
jim frost
mcde...@hcl.com (Robert McDermid) writes:
>In message <01bbe19f$e8b53520$bc900c0f@tksnet> - "Todd K"
><todd_...@hp-singapore-notes1.om.hp.com>Wed, 4 Dec 1996 04:58:53 GMT writes:
>>HPFS superior to NTFS?
>I would call these roughly equivalent - they have a few different strengths,
>but I might be willing to give NTFS a marginal (and insignifigant) win
>here.
The only really significant feature so far as I'm concerned is that it
implements security, thus allowing me to effectively protect myself
from viruses and my own stupidity. The extra reliability is nice too,
but I never had much trouble with BSD FFS so I could take it or leave
it.
The security feature is extremely significant to me, though I know
others are satisfied without it.
>>NT's multiple input queues vs. OS/2's single input queue?
>Again, both of these have plusses and minuses - it's a design decision,
>pure and simple, not superior or inferior technology.
Somebody will have to explain to me for what possible reason you would
*want* a single input queue. I can't think of any good reason other
than perhaps to save a small amount of memory -- a few bytes per
queue. That is not even close to worth the trouble it causes.
If you know of some other reason, please let me know.
>>NT's dynamic cacheing vs. OS/2's static?
>It's very debatable as to whether that dynamic cache is any advantage
>(except in poorly written benchmarks).
On my 48Mb systems I typically have 13-15Mb cache usage, which is
enough to keep me from hitting the disk in many situations. The
performance improvement can be dramatic. More on that in a minute.
>From what I understand, NT's
>dynamic cache still has a lot of problems with sucking memory away
>from other apps
This can be controlled; SunOS 4.x never had serious thrashing
problems, for instance, and AIX 3.2 and later work well too (though
AIX 3.1 thrashed like you wouldn't believe). NT 3.x certainly did
have thrashing problems, but the implementation seems to have changed
for 4.0; it works much better in low-memory situations.
>and it is doubtful that it offers much performance
>benefit in any situation except one where you have far more RAM than
>you actually need for your apps. It is highly doubtful that the benefit
>it offers is worth the cost of that extra RAM.
Memory prices have dropped about 75% in the last year, making cost
much less of an issue. It was certainly worth the $100 it cost to
upgrade my machine from 32Mb to 48Mb and cut ten minutes off each
recompilation, but YMMV.
(Sidebar: It still astounds me that people will pay hundreds of
dollars for slightly faster CPUs and skimp on memory and I/O devices
that would give much greater performance improvements for the same
cost. Most of the people running Pentium Pros would be better off
buying P100, more memory, and SCSI I/O. It's absolutely asinine to
have a chip that fast sitting there waiting for a piece-of-crap IDE
device all the time.)
>>NT's support for RAID/Mirroring vs. nothing for OS/2?
>Won't comment on this except to say in a recent comparison in PC-Week
>they said that both OSs require third party support for RAID and mirroring.
>I don't think what NT has built in is particularly useful.
NT/W doesn't have the ability to create RAID drives (though it will
work with existing RAID configurations), but NT/S does -- the only
third party support you need is additional off-the-rack disk drives.
>>NT's excellent memory protection vs. OS/2's shared dll's in memory?
>Excuse me? NT and OS/2 have exactly the same memory protection, particularly
>for dlls.
This is not correct; NT completely isolates processes from both the OS
and each other except if the process explicitly requests shared
memory. OS/2 does not, which is why it's pretty trivial to take down
OS/2 with a memory-walker while it is impossible for such a program to
take down NT.
This isolation comes at a cost, though: there is a lot less resource
sharing between different processes which share DLLs (so you need more
memory to do the same thing), and there is a higher per-process
startup cost.
>Frankly, I find OS/2 and NT to be roughly equivalent technology-wise.
I do not; OS/2 fails in two significant areas: its DLL design is far
less robust than that of NT, and OS/2 does not provide security so it
is a lot easier to screw it up. Both of these add up to a system
which is a lot less stable for a developer like myself.
I am, however, a big fan of SOM -- particularly its use by WPS. Very
nice technology.
Martin Imrisek
Graeme Adamson wrote:
>
> py...@midway.uchicago.edu (Jeremy Mathers) wrote:
>
> > Well, I think this *is* the crux of it. NT advocates like to point to the
> > advantages of journaling and security and whatever else that NTFS provides -
> > and make no mistake, these features are nifty, and may save your butt
> > someday - but are then strangely silent when the topic turns to performance.
> >
> > The TAANSTAAFL rules applies here. And, yes, accordingly to all reports,
> > including many in the otherwise MS-friendly press, Warp/HPFS performance
> > runs circles around NT/NTFS, particularly in hard-working, server-type
> > situations. You pays your money; you takes your chances.
>
> I've found NTFS quite adequate for servers, but I don't run workstations
> with it (mainly because of 95 dual booting considerations). However, there
> is now way I would even consider running a server without full security
> capabilities on the filesystem, and that knocks HPFS and FAT out of the
> running.
>
Bla bla bla... there's HPFS386, which has full security, but no
journaling.
--
------------------------------------
Martin Imrisek
*Linux: Not just for penguins anymore
jim frost
kus...@ibm.net (Gary) writes:
>>There is a more appropriate place to ask this: os2.setup maybe? I
>>tried once to BM OS/2 and NT, but when NT 'fdisk'd the drive, it
>>screwed things up royally and we were never able to get it to work.
>>And NT refused to boot OS/2 through its boot loader, so no OS/2. :(
>I had the same thing happen. There was bug in NT w/ disks over 1k
>cylinders. If you always use OS/2's fdisk though BM works great w/
>NT.
The bug you're referring to relates to using the cylinder mapping
feature of some BIOS's. Disable the mapping feature and you're fine,
though this will affect operating systems which access the disk
through the BIOS.
I ran into this one a couple of years ago, it was really annoying. We
had to swap in a different controller to work around it.
I'm mixed as to whether to call this one a bug. NT's avoidance of the
BIOS remapping during operation is a very smart thing for performance.
They probably should have been consistent in their use or avoidance of
the BIOS during install versus operation though.
jim frost
krob...@inforamp.net writes:
>Anybody got hard data or opinions about HPFS performance under NT?
>Caching issues?
Caching is done below the filesystem level so it works just fine no
matter which filesystem you're using. HPFS performance under NT used
to be very good, but it's hard for me to recommend it when it's no
longer officially supported.
jim frost
kmed...@dessus.com (Keith Medcalf) writes:
>and the number of extents does not necessarily have any impact on the
>speed of access to the hard drive.
It's nice to see somebody in this group that knows this. Multiple
extents do not always equate to slow performance!
Slower-than-optimal, sure, but with proper planning the loss can
easily be limited to a few percent of optimal (at least while the disk
is below 90% full).
>Sorry, FAT and NTFS use cluster sizes based on the size of the
>partition.
Sector clustering is typical in high-performance filesystems to
improve throughput, unlike in FAT where it was done to increase the
addressable volume size.
In NTFS the size is a tunable. From _Inside the Windows NT
Filesystem_, p. 7:
As in the FAT file system, the cluster size in NTFS is
adjustable, but it is not required to grow proportionally to
the disk size. NTFS uses a cluster size of 512 bytes on small
disks and a maximum cluster size of 4KB on large disks.
Thus the default value will not exceed 4KB regardless of volume size.
If you prefer to have a smaller or larger cluster size you can specify
it using the /A option to the format command, which states:
/A:size Overrides the default allocation unit size. Default settings
are strongly recommended for general use.
NTFS supports 512, 1024, 2048, 4096, 8192, 16K, 32K, 64K.
Since NT can address 2**64 clusters per filesystem even the smallest
possible cluster size will completely address a disk of up to 2**63
KB; plenty of room for growth.
FYI,
Michael Kraemer
The difference is that back in the days of IBM's dominance a computer
was a mainframe sitting in some company's cellar. That is, dominance didn't mean
that much because computers were sort of high tech tools/toys.
Today computers (aka PCs) are everywhere, all aspects of social life
begins to be dominated by them. He who controls these computers (via software)
controls a large part of people's daily interactions with their environment.
Still the domination of M$ is "only" 80% or so, but even this amount is not
tolerable because it gives too much (hidden) power to a single company,
which means, in the case of M$, a single man.
You know that old germany went bust shortly after the Nazi party got only
40% of the voters. Back in these bad old days it became "standard" to go with
the nazi party. It was too late for any opposition. The outcome of the whole
story is well known.
> Charles
>
Scott Ashcraft
In article <01bbe0bd$ad8d4ce0$bc900c0f@tksnet>, "Todd K"
<todd_...@hp-singapore-notes1.om.hp.com> wrote:
| Well, in my experience (a) is correct, although I don't find it
| any faster than FAT (as a file system).
Are you Loco? HPFS is *much* faster than FAT on the same system.
|
| I would take exception to point (b) however, as HPFS can definitely
| become fragmented, although, not as fast as a FAT file system can,
| due to its different design.
Slight fragmentation can occur on drives that are nearly full. I've never
defragged my OS/2 drives since I installed Warp 3 when it came out.
| NT 4.0 officially doesn't support HPFS anymore (although you can get the
| driver from NT 3.51) - MS is really lame in this regard (why would you
| drop support for a file system if you already have the driver written?!?)
This is consistent with MS's attitude towards OS/2.
scott ashcraft | email: ra4...@email.sps.mot.com
software engineer | ph. : +1.512.933.3916
motorola mos2 cim | team os/2 running wintel-free
| my opinions are my own
ls0916
Jeremy Mathers wrote:
> >Other than that, I really haven't been noticing any differences between
> >HPFS, NTFS, or FAT, realistically. I really don't think performance is
> >much of an issue if all you're going to be using the drives for is your
> >own personal use. I'm sure if you're trying to squeeze milliseconds
> >for your server, or for benchmarking, I can understand the concern, but
> >personally, I don't see ANY performance differences (VC++ compiling,
> >Netscape, etc.)
>
> This is probably all true - which indicates that NT is well-positioned as a
> consumer OS - oriented towards the novice/home user, for whom safety should
> be priority #1. It sounds like for the kind of light use you describe, NTFS
> is perfect for you.
Actually, you're wrong about NT being the well-positioned as a consumer
OS.
In fact, that OS is Win95. NT is far too security-conscious and too
complex to
learn/trouble-shoot for the novice/home user. Plus, the hardware
requirements
are (were) too high to even run the OS (I would question that now,
seeing as
though RAM is around $5 a MB, and hardware prices drop constantly).
NT is targeted to business/corporate users in a networked environment,
and as far
as I've seen, it's pretty popular out there. And for the business users
running
cc:mail, Lotus Notes, Netscape, and other popular programs, I'm sure
that
NTFS's performance is good enough. Seeing as though the original
question concerned
the person's own personal workstation, I think that NTFS's performance
on the client
side would be unnoticeable **no matter what programs they're running**.
I'm sure that
there would be a handful of bottlenecks before NTFS's performance would
become an
issue.
As for a NTFS's performance on the server side, I have no qualms that it
has poorer
performance that other file systems. I read somewhere that all of MS's
benchmarking of NT was done on FAT formatted drives. Go figure.
Steve
Travis Rushton
MS to IBM in general and Vice Versa!
tr
In article <ra4038-0512...@newsgate.sps.mot.com>,
ra4...@email.sps.mot.com says...
Christopher Curtis
I'm not too sure about the BIOS thing. Although NT was installed well
before we tried to install OS/2, I think that he had Flash-updated his
BIOS to a 1996 revision, which ended all his previous OnTrac misery.
However, I would definately call it a bug. Linux won't touch any part
of that hard drive. :(
Glenn Davies
ji...@world.std.com (jim frost) wrote:
>mcde...@hcl.com (Robert McDermid) writes:
>>In message <01bbe19f$e8b53520$bc900c0f@tksnet> - "Todd K"
>><todd_...@hp-singapore-notes1.om.hp.com>Wed, 4 Dec 1996 04:58:53 GMT writes:
>>>HPFS superior to NTFS?
>>I would call these roughly equivalent - they have a few different strengths,
>>but I might be willing to give NTFS a marginal (and insignifigant) win
>>here.
>The only really significant feature so far as I'm concerned is that it
>implements security, thus allowing me to effectively protect myself
>from viruses and my own stupidity. The extra reliability is nice too,
>but I never had much trouble with BSD FFS so I could take it or leave
>it.
>The security feature is extremely significant to me, though I know
>others are satisfied without it.
>>>NT's multiple input queues vs. OS/2's single input queue?
>>Again, both of these have plusses and minuses - it's a design decision,
>>pure and simple, not superior or inferior technology.
>Somebody will have to explain to me for what possible reason you would
>*want* a single input queue. I can't think of any good reason other
>than perhaps to save a small amount of memory -- a few bytes per
>queue. That is not even close to worth the trouble it causes.
>If you know of some other reason, please let me know.
I was under the impression that NT has a single input queue. I have
read it both ways so if you could point me to a source that does
verify that NT has multiple input queue's I would appreciate it.
[rest snipped]
--
Glenn Davies
Beldraen
ji...@world.std.com (jim frost) wrote:
>>>NT's multiple input queues vs. OS/2's single input queue?
>>Again, both of these have plusses and minuses - it's a design decision,
>>pure and simple, not superior or inferior technology.
>Somebody will have to explain to me for what possible reason you would
>*want* a single input queue. I can't think of any good reason other
>than perhaps to save a small amount of memory -- a few bytes per
>queue. That is not even close to worth the trouble it causes.
>If you know of some other reason, please let me know.
I am not an expert, but from the discussions of delevopers I have seen
is this: First of all, both OS/2 and NT do NOT have single input
queues. Both are multiple. The problem is the difference between
Sync and Async queues. OS/2's sync queue came from when MS designed
the original interface. Sync is a lot easier to implement due to ONE
queue from input devices feeding all the queues of the apps. You
don't have to worry about timing when the input came in. But, if the
queues from the apps don't come and get their info, the main queue is
stopped and plugged up. The async queue however must be timed. For
instance, if I select another window and start typing, that window may
not realize yet that it has focus. But, then another window jumps in
front of you with a dialog box and takes focus. Do you 1) try to keep
track of what window should have gotten the key strokes, 2) send the
key strokes to the dialog box or 3) throw the key strokes out? As I
understand it, while one is the best answer, it is not easy to do and
as the old saying goes, the more there is, the easier it is for it all
to break. Plus, from a programming stance, when you create new
windows in a sync queue you can be guarenteed where keystrokes go, but
in an async environment you have to watch what you are doing. It's
one of the reason the sync queue in OS/2 has stuck around.
Supposedly, it would break various apps that don't watch their timing.
Frankly, I'd take app breakage for not having the WPS ever be able to
lock me up. It's the only type of crash that stops my machine
anymore. Everything else runs like a champ.
Bel, the mostly sane...
Eagles may fly, but weasles don't get sucked into jet engines.
jim frost
>>>Again, both of these have plusses and minuses - it's a design decision,
>>>pure and simple, not superior or inferior technology.
>>Somebody will have to explain to me for what possible reason you would
>>*want* a single input queue. I can't think of any good reason other
>>than perhaps to save a small amount of memory -- a few bytes per
>>queue. That is not even close to worth the trouble it causes.
>>If you know of some other reason, please let me know.
>I was under the impression that NT has a single input queue. I have
>read it both ways so if you could point me to a source that does
>verify that NT has multiple input queue's I would appreciate it.
NT actually has one input queue per thread. From the October 1996
MSDN Library documentation, Win32 SDK Reference, Overviews, Window
Management, Messages and Message Queues, About Messages and Message
Queues, Message Routing, Queued Messages (whew! page numbers were
easier):
Windows maintains a single system message queue and any number
of thread message queues, one for each GUI thread. To avoid
the overhead of creating a message queue for non-GUI threads,
all threads are created initially without a message queue. The
system creates a thread's message queue only when the thread
makes its first call to one of the Win32 API User or GDI
functions.
(FWIW, if you're working with Windows the MSDN Library subscription is
the best $99 you'll ever spend.)
jim frost
ra4...@email.sps.mot.com (Scott Ashcraft) writes:
>| I would take exception to point (b) however, as HPFS can definitely
>| become fragmented, although, not as fast as a FAT file system can,
>| due to its different design.
>Slight fragmentation can occur on drives that are nearly full. I've never
>defragged my OS/2 drives since I installed Warp 3 when it came out.
This is not correct; fragmentation occurs as a matter of course in use
even when the filesystem is completely empty. What's different from
FAT is that HPFS attempts to allocate space such that the latency
increase due to fragmentation is minimized. This is pretty easy to do
until the drive becomes more than 90% full (according to empirical
observations done by the Berkeley folks).
The practical result is that, even though fragmentation is occurring,
it does little to affect system performance until you get to the
pathological cases seen when the drive is nearly full.
If you're intersted in more information I can give you pointers to the
Berkeley FFS papers.
Technically speaking FAT could do this if somebody wanted to rewrite
the block allocator; you don't need a complete filesystem redesign.
Interactive UNIX used such an algorithmic change to improve the
fragmentation behavior of UFS years ago, with excellent success.
Sangria
On 5 Dec 1996 21:05:00 GMT, ra4...@email.sps.mot.com (Scott Ashcraft)
wrote:
>| I would take exception to point (b) however, as HPFS can definitely
>| become fragmented, although, not as fast as a FAT file system can,
>| due to its different design.
>
>Slight fragmentation can occur on drives that are nearly full. I've never
>defragged my OS/2 drives since I installed Warp 3 when it came out.
Look, face it, practically all file systems fragment. Some fragment
more than others, but the real problem isn't whether a file system
fragment or not, but how it impacts the given system.
NTFS, HPFS, FAT, VFAT, FAT32, et. al. all fragment. The difference
is that when FAT fragments heavily, DOS becomes next to useless.
I have an NTFS defragger on my NT machine. The performance difference
between somewhat fragmented to no fragmentation is unnoticable. The
performance difference between extremely fragmented to no
fragmentation is noticable.
I recall when DOS/Windows had the FAT drives heavily fragmented, the
system spent more time cooking the harddrive than actually doing work.
>| NT 4.0 officially doesn't support HPFS anymore (although you can get the
>| driver from NT 3.51) - MS is really lame in this regard (why would you
>| drop support for a file system if you already have the driver written?!?)
>
>This is consistent with MS's attitude towards OS/2.
In someways it makes sense.
If I were trying to phase out support for a given file system or OS
component, I have two choices:
1. Completely cut off support and consequently leave some of the
users in a lurch.
2. Officially stop supporting it, but still allow for a way to work
with it even if it's no longer supported.
I think if MS did it the other way, you'd hear a lot more people
screaming. I fully expect NT 5.0 to drop support for HPFS completely.
-- Sang.
********************************************************
* Sang K. Choe san...@inlink.com *
* http://sangria.inlink.com/index.html *
* finger: sa...@sangria.inlink.com *
********************************************************
Thomas G. McWilliams
Todd K (todd_...@hp-singapore-notes1.om.hp.com) wrote:
: HPFS superior to NTFS?
As stated previously, NT's NTFS is slow and subject to fragmentation.
OS/2 HPFS is superior to NTFS in both categories. For server use
OS/2 HPFS wins hands down. In terms of file system performance,
it is fair to say NT is "Not There".
Glenn Davies
san...@inlink.com (Sangria) wrote:
But why drop support at all? It's already dropped now, why wait for
5.0?
--
Glenn Davies
Sangria
On Sat, 07 Dec 1996 09:35:52 GMT, gl...@direct.ca (Glenn Davies)
wrote:
>>>| NT 4.0 officially doesn't support HPFS anymore (although you can get the
>>>| driver from NT 3.51) - MS is really lame in this regard (why would you
>>>| drop support for a file system if you already have the driver written?!?)
>>>
>>>This is consistent with MS's attitude towards OS/2.
>
>>In someways it makes sense.
>
>>If I were trying to phase out support for a given file system or OS
>>component, I have two choices:
>
>>1. Completely cut off support and consequently leave some of the
>>users in a lurch.
>
>>2. Officially stop supporting it, but still allow for a way to work
>>with it even if it's no longer supported.
>
>>I think if MS did it the other way, you'd hear a lot more people
>>screaming. I fully expect NT 5.0 to drop support for HPFS completely.
>
>But why drop support at all? It's already dropped now, why wait for
>5.0?
Well, given that their Win32 Common Driver model is going to be
incorporated with NT 5.0 so the driver code base between Win95 and
WinNT can be shared, I'd say the odds that the current HPFS driver
will work with the next version would be extremely unlikely.
Of course, this doesn't stop anyone from writing a driver for HPFS to
work with NT 5.0. I just don't think too many people would bother by
that time. I know MS will most likely not spend the time. Some sites
which has a lot of OS/2 and NT working together might, but again, I
find the possibility low.
William de Haan
On Thu, 05 Dec 1996 19:16:32 -0500, ls0916 <ls0...@netcom.ca> wrote:
>Jeremy Mathers wrote:
>Actually, you're wrong about NT being the well-positioned as a consumer
>OS. In fact, that OS is Win95. NT is far too security-conscious and too
>complex to learn/trouble-shoot for the novice/home user. Plus, the
True. Of course, W95 and WNT are converging, so I expect that we'll see
WNT pushed into the home market within 2-3 years.
>hardware requirements are (were) too high to even run the OS (I would
>question that now, seeing as though RAM is around $5 a MB, and hardware
>prices drop constantly).
One of the standard rules of computing is that capacity is doubling
about every 18 months. Hell, the VTD in Warp 4 would have been
considered a joke just two years ago. Remember that OS/2 v1.3 was
released to run in 2MB because OS/2 v1.2 was "bloated" at 3MB. At the
time, that was a $500 difference.
________________________________________________________________________
William de Haan b...@deus.com 905-281-3523 Voice 905-281-3524 Fax
Deus Ex Machina Ltd., 3650 Kaneff Crescent, Mississauga, Ontario L5A 4A1
"No more tears now; I will think upon revenge." - Mary Queen of Scots.
William de Haan
On 5 Dec 1996 17:45:53 GMT, kra...@biori6k.gsi.de (Michael Kraemer)
wrote:
>The difference is that back in the days of IBM's dominance a computer
>was a mainframe sitting in some company's cellar. That is, dominance
>didn't mean that much because computers were sort of high tech
>tools/toys.
Dominance meant EVERYTHING. What, you don't think the fact that the
government was dependant on IBM technology didn't have any effect?
>Still the domination of M$ is "only" 80% or so, but even this amount is
>not tolerable because it gives too much (hidden) power to a single
>company, which means, in the case of M$, a single man.
But unlike the IBM days, MS isn't the only game in town for a lot of
this stuff. Nobody has to use a PC, there's nothing wrong with a Mac or
an Amiga.
>You know that old germany went bust shortly after the Nazi party got
>only 40% of the voters. Back in these bad old days it became "standard"
>to go with the nazi party. It was too late for any opposition. The
>outcome of the whole story is well known.
Bzzzt. Godwin's Law. You lose.
William de Haan
On Fri, 06 Dec 1996 09:17:59 GMT, gl...@direct.ca (Glenn Davies) wrote:
>ji...@world.std.com (jim frost) wrote:
>I was under the impression that NT has a single input queue. I have read
Nope, NT and OS/2 both have multiple queues. The question is whether or
not they are synchronous or not. PM's is, NT's isn't.
>it both ways so if you could point me to a source that does verify that
>NT has multiple input queue's I would appreciate it.
TCP/IP Programming for OS/2
Steven Gutz
ISBN-1-884777-17-1
pp17-18
Tom Canham
This is off-topic.
Having read Helen Custer's "Inside the NT File System", I know that a lot
of the theories about NTFS posted here are hooey (NTFS as derived from
FAT?? PuhLEAZE).
It's nice to see a rational, not-too-preachy opinion once in a while :)
--
-- Tom Canham
tom_c...@3mail.3com.com
the 3Com Interoperability Labs
"The views expressed above do not blah blah..."
cro...@kuentos.guam.net
In <32a8d479.2593937@snoopy>, san...@inlink.com (Sangria) writes:
>On 5 Dec 1996 21:05:00 GMT, ra4...@email.sps.mot.com (Scott Ashcraft)
>wrote:
>
>>| I would take exception to point (b) however, as HPFS can definitely
>>| become fragmented, although, not as fast as a FAT file system can,
>>| due to its different design.
>>
>>Slight fragmentation can occur on drives that are nearly full. I've never
>>defragged my OS/2 drives since I installed Warp 3 when it came out.
>
>Look, face it, practically all file systems fragment. Some fragment
>more than others, but the real problem isn't whether a file system
>fragment or not, but how it impacts the given system.
>
>NTFS, HPFS, FAT, VFAT, FAT32, et. al. all fragment. The difference
>is that when FAT fragments heavily, DOS becomes next to useless.
>
>I have an NTFS defragger on my NT machine. The performance difference
>between somewhat fragmented to no fragmentation is unnoticable. The
>performance difference between extremely fragmented to no
>fragmentation is noticable.
>
>I recall when DOS/Windows had the FAT drives heavily fragmented, the
>system spent more time cooking the harddrive than actually doing work.
>
I have an HPFS defragger, and all it really ever did was to regroup the files.
It should be called a file defagger, instead of a disk defragger.
I didn't notice any difference before and after "defragging".
Rgds,
Chris
Famous People on Operating Systems (Please feel free to contribute)
Edgar Allen Poe, writing a poem when his PC crashed---
"Microsoft, nevermore, nevermore."
President Roosevelt, during the day Windows 95 is launched---
"This day shall live in infamy."
Thanks to those who contributed. ***cro...@kuentos.guam.net***
Glenn Davies
san...@inlink.com (Sangria) wrote:
>On Sat, 07 Dec 1996 09:35:52 GMT, gl...@direct.ca (Glenn Davies)
>wrote:
>>>>| NT 4.0 officially doesn't support HPFS anymore (although you can get the
>>>>| driver from NT 3.51) - MS is really lame in this regard (why would you
>>>>| drop support for a file system if you already have the driver written?!?)
>>>>
>>>>This is consistent with MS's attitude towards OS/2.
>>
>>>In someways it makes sense.
>>
>>>If I were trying to phase out support for a given file system or OS
>>>component, I have two choices:
>>
>>>1. Completely cut off support and consequently leave some of the
>>>users in a lurch.
>>
>>>2. Officially stop supporting it, but still allow for a way to work
>>>with it even if it's no longer supported.
>>
>>>I think if MS did it the other way, you'd hear a lot more people
>>>screaming. I fully expect NT 5.0 to drop support for HPFS completely.
>>
>>But why drop support at all? It's already dropped now, why wait for
>>5.0?
>Well, given that their Win32 Common Driver model is going to be
>incorporated with NT 5.0 so the driver code base between Win95 and
>WinNT can be shared, I'd say the odds that the current HPFS driver
>will work with the next version would be extremely unlikely.
So all device drivers are going to have to rewritten? Didn't all
video drivers have to be rewritten for 4.0 and now they have to change
again?
--
Glenn Davies
Glenn Davies
b...@deus.com (William de Haan) wrote:
>On Fri, 06 Dec 1996 09:17:59 GMT, gl...@direct.ca (Glenn Davies) wrote:
>>ji...@world.std.com (jim frost) wrote:
>>I was under the impression that NT has a single input queue. I have read
>Nope, NT and OS/2 both have multiple queues. The question is whether or
>not they are synchronous or not. PM's is, NT's isn't.
Thanks for the info but that is not what I meant. I'm thought Jim was
talking about the system input queue.
--
Glenn Davies
Glenn Davies
ji...@world.std.com (jim frost) wrote:
>gl...@direct.ca (Glenn Davies) writes:
>>>>>NT's multiple input queues vs. OS/2's single input queue?
>>>>Again, both of these have plusses and minuses - it's a design decision,
>>>>pure and simple, not superior or inferior technology.
>>>Somebody will have to explain to me for what possible reason you would
>>>*want* a single input queue. I can't think of any good reason other
>>>than perhaps to save a small amount of memory -- a few bytes per
>>>queue. That is not even close to worth the trouble it causes.
>>>If you know of some other reason, please let me know.
>>I was under the impression that NT has a single input queue. I have
>>read it both ways so if you could point me to a source that does
>>verify that NT has multiple input queue's I would appreciate it.
>NT actually has one input queue per thread. From the October 1996
>MSDN Library documentation, Win32 SDK Reference, Overviews, Window
>Management, Messages and Message Queues, About Messages and Message
>Queues, Message Routing, Queued Messages (whew! page numbers were
>easier):
Sorry more misunderstanding, I thought you were talking about the
system input queue. I found that Richter gave an better description
than Custer and that is where I originally found some ambiguity.
>(FWIW, if you're working with Windows the MSDN Library subscription is
>the best $99 you'll ever spend.)
I agree I've been along time Level 2 subscriber.
--
Glenn Davies
141.192.83.61
In <32abdb2d...@196.4.160.8>, clay...@spl.co.za (Graeme Adamson) writes:
>mcde...@hcl.com (Robert McDermid) wrote:
>> In message <01bbe19f$e8b53520$bc900c0f@tksnet> - "Todd K"
>> <todd_...@hp-singapore-notes1.om.hp.com>Wed, 4 Dec 1996 04:58:53 GMT writes:
>> >HPFS superior to NTFS?
>> I would call these roughly equivalent - they have a few different strengths,
>> but I might be willing to give NTFS a marginal (and insignifigant) win
>not a marginal win at all.
True. Good point.
>> >NT's dynamic cacheing vs. OS/2's static?
>The benefit is flexibility. If you have an app that does need a lot of
>memory (Photoshop for example), it can be given to that app without
>compromising your disk performance with a smaller cache for other programs
>when the app isn't running.
Dynamic cache has its problems. It is difficult
to implement dynamic cache to be optimal in all
cases - just think of the Win95-implementation!
NT does it better, but the foreground app still gets
unnecessarily sluggish if you have a disk intensive
task (XCOPY) running in backgound. (I would
expect no speed penalty for the foreground app.)
>> >NT's support for RAID/Mirroring vs. nothing for OS/2?
>It works very nicely, thank you.
RAID is in NT Server product only. And it works nicely.
>In PC Magazine earlier this year, NT was rated as being better protected
>than OS/2. They created programs designed to crash programs and the OS, and
>they couldn't crash NT.
NT is stable, true, but if the were not _able_ to crash NT,
they were not really trying very hard...
>> Let's see what else we have
>> SOM/DSOM vs COM and the Not Here Yet DCOM
>Has it made a difference in anyone's life?
>> WPS vs that Explorer thing (ugh)
>Explorer vs that WPS thing (ugh)
>> Opendoc vs OLE (double ugh)
Most of above are a matter of taste, but can you find
a programmer who would praise elegance of OLE?
>Rexx and Perl run quite happily on NT (both available with the NT ResourceKit).
but cost extra money
best regards,
Kari Kamunen
Sangria
On 9 Dec 1996 15:07:34 GMT, 141.192.83.61@ wrote:
>>> >NT's support for RAID/Mirroring vs. nothing for OS/2?
>>It works very nicely, thank you.
>
>RAID is in NT Server product only. And it works nicely.
RAID isn't a singular item.
NTW support RAID 0 directly in software. NTS supports RAID 0, 1, 2
and 5 directly in software.
Carlos Meelboom Rivera
Im curious in this topic, does NT 4.0 with HPFS support installed support
the security features of HPFS or are the security features available only
in NTFS?
Thanks
Carlos Meelboom
James Knott
In article <58fks4$3...@lehi.kuentos.guam.net>, cro...@kuentos.guam.net wrote:
>I have an HPFS defragger, and all it really ever did was to regroup the files.
>It should be called a file defagger, instead of a disk defragger.
Why are you so concerned with "disk" degragmenting? As long as the files are
contiguous, what's the problem. Those spaces between files will allow
existing files to grow, and may also be used for new files. As I recall, HPFS
tries to balance the files over the entire disk.
Keith Medcalf
In <Pine.SGI.3.91.96120...@anubis.ciateq.conacyt.mx>, Carlos Meelboom Rivera <el...@anubis.ciateq.conacyt.mx> writes:
>Im curious in this topic, does NT 4.0 with HPFS support installed support
>the security features of HPFS or are the security features available only
>in NTFS?
Microsoft's implementation of HPFS in NT is limited to the "baby-HPFS"
varient of the filesystem, which cannot maintain ACL data on the disk
(it can, however, in most implementations, read the ACL data). Whether
or not they follow the HPFS baby-spec and deny access to ACL protected
filesystem objects is another matter, the answer to which I do not know.
-------------------------------------------------------------
Keith Medcalf (416) 410-5791 http://www.dessus.com/
Keith Medcalf & Associates, 152-275 Broadview Avenue, Toronto
IBM OS/2, LAN Server, DB2/2, TCP/IP, DOS, Windows, Windows NT
IBM System Management Software Specialist IBM BESTeam Member
IBM OS/2 Warp Server Software Specialist
jim frost
kmed...@dessus.com (Keith Medcalf) writes:
>In <Pine.SGI.3.91.96120...@anubis.ciateq.conacyt.mx>, Carlos Meelboom Rivera <el...@anubis.ciateq.conacyt.mx> writes:
>>Im curious in this topic, does NT 4.0 with HPFS support installed support
>>the security features of HPFS or are the security features available only
>>in NTFS?
>Microsoft's implementation of HPFS in NT is limited to the "baby-HPFS"
>varient of the filesystem, which cannot maintain ACL data on the disk
>(it can, however, in most implementations, read the ACL data). Whether
>or not they follow the HPFS baby-spec and deny access to ACL protected
>filesystem objects is another matter, the answer to which I do not know.
It ignores the security information.
krob...@inforamp.net
In <Pine.SGI.3.91.96120...@anubis.ciateq.conacyt.mx>, Carlos Meelboom Rivera <el...@anubis.ciateq.conacyt.mx> writes:
>Im curious in this topic, does NT 4.0 with HPFS support installed support
>the security features of HPFS or are the security features available only
>in NTFS?
>
Is the hpfs386 format different from hpfs or is it just the extendend attibutes
contain security information that hpfs386 reads and hpfs disregards?
I might cross post this one.
Best Regards,
Alan Burns
In message <32aaa73a.48500859@snoopy> - san...@inlink.com (Sangria) writes:
>>But why drop support at all? It's already dropped now, why wait for
>>5.0?
>
>Well, given that their Win32 Common Driver model is going to be
>incorporated with NT 5.0 so the driver code base between Win95 and
>WinNT can be shared, I'd say the odds that the current HPFS driver
>will work with the next version would be extremely unlikely.
You've rather skillfully evaded the question. :-) The question is why they
would drop it in 4.0, not 5.0. The 3.51 driver obviously works just fine
since everybody is using it, so why take it out when it works?
Regards,
Alan Burns
abu...@sunset.backbone.olemiss.edu
http://www.olemiss.edu/~aburns
David LeBlanc
141.192.83.61@ wrote:
>>Rexx and Perl run quite happily on NT (both available with the NT ResourceKit).
>but cost extra money
The resource kit may cost a little (IMHO, well worth it), but both
perl and rexx are available freely from ftp.microsoft.com, as well as
several other sites.
David LeBlanc | We do not want computers that do more,
dleb...@mindspring.com | we want computers that do less.
| Oracle Chairman Larry Ellison
Hendrik H. Fulda
In <58krvm$s...@news.inforamp.net>, krob...@inforamp.net writes:
>>
>HPFS doesn't have any security. HPFS386 does though. Hold the phone...
>Is the hpfs386 format different from hpfs or is it just the extendend attibutes
>contain security information that hpfs386 reads and hpfs disregards?
ACLs (Access Control Lists) can be added to files and directories in HPFS
using the HPFS386 Installable File System Driver. The logical structure of
the disk is not altered. With ACLs present, the normal HPFS is not able to
access a file. If you remove the ACLs with a utility (ACLPREP or so, provided
with LAN Server), the FS becomes available to the normal HPFS again,
this is needed (for example) for updating the base OS.
With installing "local security", you will have to logon to the server machine
locally as if you where connecting from the LAN. "Local security" is provided
with LAN Server (Warp Server etc.).
If you need "real" security at the Server machine, you need more than HPFS386:
IBM SafeGuard Desktop or Professional (which goes far beyond the security
NT provides). Security from the LAN is on par with NT and will be even better
with IBMs Directory and Security Services (using Kerberos, which MS is also
going to use, AFAIK).
Hope this helps
Hendrik
---
Hendrik H. Fulda, IBM Certified OS/2 Engineer, TeamOS/2
eMail: h...@pop.de, h...@teamos2.de, Phone: +49 177 215 10 09
Travel to any part of the internet without moving, by folding the
cyberspace with simple words. The spell of Merlin will take you
everywhere and back - at Warp speed! http://www.teamos2.de/
---
Sangria
On 11 Dec 1996 02:53:22 GMT, abu...@sunset.backbone.olemiss.edu (Alan
Burns) wrote:
>In message <32aaa73a.48500859@snoopy> - san...@inlink.com (Sangria) writes:
>
>>>But why drop support at all? It's already dropped now, why wait for
>>>5.0?
>>
>>Well, given that their Win32 Common Driver model is going to be
>>incorporated with NT 5.0 so the driver code base between Win95 and
>>WinNT can be shared, I'd say the odds that the current HPFS driver
>>will work with the next version would be extremely unlikely.
>
>You've rather skillfully evaded the question. :-) The question is why they
>would drop it in 4.0, not 5.0. The 3.51 driver obviously works just fine
>since everybody is using it, so why take it out when it works?
If you read the earlier post, I postulated why they might do it this
way:
Since Microsoft wants to drop support for HPFS. They can do it two
ways:
1. Drop it completely in the next version, potentially leaving people
in a lurch.
2. "Official" drop support for it in the next version but allow a way
to shoe-horn support in for those needing to gradually migrate off.
Since NT 5.0 is going to have a different driver model than previous
NT versions, it would make complete sense to do it before NT 5.0 if
they wanted to give the users an option to gradually migrate off. And
the version before NT 5.0 is NT 4.0.
Obviously, this is just a guess on my part, but it appears to make
sense--at least to me.
Art Doyle
rho...@seal.gtri.gatech.edu (Robert L. Howard) wrote:
>
>I'm a long time OS/2 user (since 2.1), currently using Warp v4.
>
>I use HPFS for all partitions based on the conventional wisom of:
> a) HPFS is faster ("high performance")
> b) HPFS doesn't suffer from fragmentation
>
>Therefore:
> a) Everyone seems to recommend HPFS (plus you get long filenames, etc.)
> b) Nobody bothers to make / buy HPFS de-fragmentation programs.
>
>I will soon be using NT 4.0 on this same machine (don't really want to
>but must). I am really confused about my filesystem options.
>
>My understanding always was that NT was an outgrowth of HPFS (Microsoft
>"created" both). Yet from gleaning NT newsgroups I discover:
> a) Most (including MS) recommend FAT as faster
> b) The need for and supply of de-fraggers is rampant
>
>What gives? Is NT really that bad? I understand other reasons why I would
>want to use NTFS (long names, security, etc.) but what kiknd of performance
>hit am I talking about here? Am I really going to step back to the "bad
>old days" and start worrying about fragmentation again (I never worry
>about it on UNIX either).
>
>So how should I partition / format my drive for NT? Also would be willing
>to accept recommendation on making NT / Warp work together in a boot manager
>environment so I can use both on the same machine....
>
>Thanks,
>Robert
>--
>| Robert L. Howard | Georgia Tech Research Institute |
>| robert...@gtri.gatech.edu | SEAL / ATDD |
>| (770) 528-7165 | Atlanta, Georgia 30332 |
>-------------------------------------------------------------------------
>|"Government subsidies can be critically analyzed according to a simple |
>| principle: You are smarter than the government, so when the government|
>| pays you to do something you wouldn't do on your own, it is almost |
>| always paying you to do something stupid." -- P.J. O'Rourke |
I run both Warp 4.0 and NT 4.0. The NT is hacked with the pinball
modification so that it can share a large HPFS partition....but it
sometimes generates problems. The MS HPFS does not seem to be
identical to IBM's HPFS.
Despite minor problems, I like and use both systems. Of the two, NT
seems to be more conservative and bulletproof. It shows a high degree
of polish, and is very very predictable/reliable. I keep all my
financial records only on NTFS drives. The Warp system seems to have a
more robust connectivity, and seems to push the "state of the art"
more than MS ....but at the expense of much reduced reliability. I
would never entrust Warp with something I *had* to keep.
Other weird characteristics...NT has a *serious* file fragmentation
problem, and if you don't get that Diskeeper program installed and
running IMMEDIATELY after installation - you will be sorry. Warp on
the other hand seems often to be slower for disk access than NT. I
suspect this is a consequence of a poorly implemented HPFS cache. The
NT cache is truly superb.
I tend to use Warp for fun, and NT for business use.
Hope this helps,
Art
David LeBlanc
san...@inlink.com (Sangria) wrote:
>On 11 Dec 1996 02:53:22 GMT, abu...@sunset.backbone.olemiss.edu (Alan
>Burns) wrote:
>>You've rather skillfully evaded the question. :-) The question is why they
>>would drop it in 4.0, not 5.0. The 3.51 driver obviously works just fine
>>since everybody is using it, so why take it out when it works?
>Since NT 5.0 is going to have a different driver model than previous
>NT versions, it would make complete sense to do it before NT 5.0 if
>they wanted to give the users an option to gradually migrate off. And
>the version before NT 5.0 is NT 4.0.
I think you're right on this one - as you likely recall, they removed
the option of formatting an HPFS partition in NT 3.51, but would still
read it. Then in 4.0, they don't even want to read it. My guess
would be that not very many people screamed when they removed the
ability to create an HPFS partition, so they continued. I still think
it is rude of them not to even read it, when clearly the old driver
still works - why not provide it, but just make it very clear that the
bus stops at 5.0?
David LeBlanc |Why would you want to have your desktop user,
dleb...@mindspring.com |your mere mortals, messing around with a 32-bit
|minicomputer-class computing environment?
|Scott McNealy
Tim Smith
Alan Burns <abu...@sunset.backbone.olemiss.edu> wrote:
>>Well, given that their Win32 Common Driver model is going to be
>>incorporated with NT 5.0 so the driver code base between Win95 and
>>WinNT can be shared, I'd say the odds that the current HPFS driver
>>will work with the next version would be extremely unlikely.
>
>would drop it in 4.0, not 5.0. The 3.51 driver obviously works just fine
>since everybody is using it, so why take it out when it works?
If they are planing to go to a new driver model in 5.0, which means the
old HPFS driver won't work, then it makes a lot of sense to drop it
officially in 4.0. By dropping it in 4.0, when it still works, they
can get most of their users to switch now, while those who cannot for
some reason will run the 3.51 version, but might at least wake up and
realize that it is going to really go away in 5.0, and be ready to
switch then.
It's almost always best to have a transition version where the things
you are trying to get rid of still work, perhaps with some kludging
by the user.
--Tim Smith
Alan Burns
In message <32b0beab.180381265@snoopy> - san...@inlink.com (Sangria)Fri, 13
Dec 1996 02:28:52 GMT writes:
>Since Microsoft wants to drop support for HPFS. They can do it two
>ways:
>
>1. Drop it completely in the next version, potentially leaving people
>in a lurch.
>
>2. "Official" drop support for it in the next version but allow a way
>to shoe-horn support in for those needing to gradually migrate off.
>
>Since NT 5.0 is going to have a different driver model than previous
>NT versions, it would make complete sense to do it before NT 5.0 if
>they wanted to give the users an option to gradually migrate off. And
>the version before NT 5.0 is NT 4.0.
I suppose I see your point as far as that goes. I guess what I really have a
problem with (and you say this much yourself) is that they clearly *want* to
get rid of it. From a business perspective, I can see why they would try to
alienate OS/2, and it's certainly legitimate for them to do that.
But think about it - they're *removing* features from their product in order
to force people to use it, instead of adding features and allowing the product
stand on its own merits. It seems like everybody else is trying to create
cross-platform compatibility, and Microsoft is the only one systematically
trying to break it. That may be good hardball business, but it's not what I
would call a roadmap for progress.
Malcolm Chan
Art Doyle wrote:
> Other weird characteristics...NT has a *serious* file
fragmentation
> problem, and if you don't get that Diskeeper program installed and
> running IMMEDIATELY after installation - you will be sorry. Warp
on
> the other hand seems often to be slower for disk access than NT. I
> suspect this is a consequence of a poorly implemented HPFS cache.
The
> NT cache is truly superb.
It seems strange that NTFS would have serious file fragmentation
problems... pity. As for the disk cache, I've found even smartdrive
to
perform better than the HPFS cache under OS/2. That, too, is a
pity,
since it gives many a first impression is that HPFS is much slower
than
FAT.
--
Malcolm Chan (English), Zeng Qiangyong (Chinese) _/ _/
_/_/_/
Student, Computer Science Department _/_/ _/_/ _/
University of Auckland _/ _/ _/ _/
EMail Address: mal...@kcbbs.gen.nz _/ _/ _/_/_/
Illya Vaes
san...@inlink.com (Sangria) writes:
>Since NT 5.0 is going to have a different driver model than previous
>NT versions, it would make complete sense to do it before NT 5.0 if
And here I thought that NT 4.0 already had a new driver model (which is why
there were relatively little drivers and people were bitching about it, though
ofcourse "understanding" of the issue).
--
Illya Vaes (iv...@hr.ns.nl) Not speaking for anyone but myself
Holland Railconsult BV, Railtraffic Systems, Control Systems
Postbus 2855, 3500 GW Utrecht
Tel +31.30.2358586, Fax 2357202 "Do...or do not, there is no try" - Yoda
Sangria
On Tue, 17 Dec 1996 10:36:43 GMT, Illya Vaes <iv...@hr.ns.nl> wrote:
>san...@inlink.com (Sangria) writes:
>>Since NT 5.0 is going to have a different driver model than previous
>>NT versions, it would make complete sense to do it before NT 5.0 if
>
>And here I thought that NT 4.0 already had a new driver model (which is why
>there were relatively little drivers and people were bitching about it, though
>ofcourse "understanding" of the issue).
Sure, every other OS that I can think of also changed driver models
when they went from one version to the next.
However, the "good news" of this upgrade is that the new driver model
will be the Win32 Common Driver Model (I think that's the name). This
allows drivers written for Win95 to be rewritten (I recall someone
saying it was just a recompile--at least for the x86 versions) very
easily for WinNT. It should make the lack of driver issue somewhat
better for the NT users.
Sangria
>Art Doyle wrote:
>> Other weird characteristics...NT has a *serious* file fragmentation
>> problem, and if you don't get that Diskeeper program installed and
>> running IMMEDIATELY after installation - you will be sorry.
If you're using the DiskKeeper analysis tool to determine this level
of fragmentation, you should realize that this analysis tool is
somewhat overly zealous about tagging a file as "fragmented". I found
a cleanly formatted drive with less than 10% filled to be "moderately"
fragmented using the analysis tool.
>It seems strange that NTFS would have serious file fragmentation
>problems... pity.
I think the DiskKeeper tool is just a tad too pessimistic.
jim frost
It sells more product if you're pessimistic. Personally I consider it
too simplistic to measure fragmentation as a count of file extents;
the number of extents matters a lot less than they're relative
locations.
Bob Shair
rho...@seal.gtri.gatech.edu (Robert L. Howard) wrote:
>
>I'm a long time OS/2 user (since 2.1), currently using Warp v4.
>
>I use HPFS for all partitions based on the conventional wisom of:
> a) HPFS is faster ("high performance")
> b) HPFS doesn't suffer from fragmentation
moving from all OS/2 to both OS/2 and NT 4.0 .
>So how should I partition / format my drive for NT? Also would be willing
>to accept recommendation on making NT / Warp work together in a boot manager
>environment so I can use both on the same machine....
Well, I've only had the machine for two days, but the following procedure
seems to work so far.
Machine came in with 2.1GB SCSI drive, NT 4.0 Workstation installed
in a single FAT partition (Ugh!!).
Booted OS/2 Warp 4 installation disks... exited to a prompt.
From my Partition Magic 2.0 floppy, ran PQMAGICT,
..) Shrank C: to 251MB (where FAT performs fine)
..) Installed OS/2 Boot Manager
..) Made the rest of the disk a Logical Partition area
..) Created a 400+ MB HPFS D: partition (at start) for OS/2 and apps
..) Created a 500 MB HPFS F: partition (at end)
(for a complete image of my old computer's hard file)
..) Created a 251MB FAT partition (at end) for Windows Applications
Installed OS/2 Warp 4 onto the D: partition
Installed OS/2 Applications onto the D: partition, including Backmaster
Used Backmaster to restore my old computer's backup to the F: partition
Booted NT,
Installed Windows applications on E:
Discovered that NT couldn't see the HPFS partitions,
(research on the Net)
Grabbed pinball.sys from a departmental NT 3.51 system and installed it.
NT can now read, write, and close HPFS partitions
Booted OS2 (didn't complain about what NT had done to the D: drive)
Tried running Windows applications off the E: drive
(research on the Net)
Created a /LIB/DLL/WINDOWS directory on D:
Copied the DLLs from /WINDOWS/SYSTEM on F: (old computer)
(was running Warp 3 Red Spine (for Windows))
As I have it set up now, All partitions are accessible from either
operating system, and have the same drive letters.
A: Floppy
C: NT System FAT (should be static, and not require reorgs or defrags)
D: OS/2 Syst HPFS
E: Win Apps FAT (might move to HPFS, or NTFS if OS/2 can handle it)
F: Old Sys HPFS
G: CD-ROM
Still to do (lots):
Use Unimaint to restore appearance of Warp3 desktop
Convince OS/2 and NT to share the same Swap Space
Learn NT!
So far, I'm pretty impressed witn NT. It feels very quick,
perhaps even quicker than Warp, (on a PentimPro 200 with 64MB).
My wife has always complained that every time she uses the computer
she has to learn it over, since I'm always changing things. With
NT, she can keep her login static.
It's Netnews and the Web that make it possible to actually make these
beasts work!
--
Bob Shair Open Systems Consultant
1018 W. Springfield Avenue rms...@uiuc.edu
Champaign, IL 61821 217/356-2684
< Not employed by or representing the University of Illinois >
OperaGhost
In <32B757...@kcbbs.gen.nz>, Malcolm Chan <mal...@kcbbs.gen.nz> writes:
>Art Doyle wrote:
>> Other weird characteristics...NT has a *serious* file
>fragmentation
>> problem, and if you don't get that Diskeeper program installed and
>on
>> the other hand seems often to be slower for disk access than NT. I
>> suspect this is a consequence of a poorly implemented HPFS cache.
>The
>> NT cache is truly superb.
>
>to
>perform better than the HPFS cache under OS/2. That, too, is a
>pity,
>since it gives many a first impression is that HPFS is much slower
>than
>FAT.
Actually, even with the lousy cache under Warp 3.0, HPFS still outperforms
NTFS, because of all the "gizmos" built into it for file security and such.
As far as warp 4.0, well, the HPFS cache is a hell of a lot better with read-
ahead but a dynamic cache, shared with FAT and CDFS is what's really needed.
----------------------------------
Stephen Eickhoff
eti...@microserve.net
http://www.microserve.net/~etienne
[Team OS/2]
[Phi Mu Alpha Sinfonia]
----------------------------------
Andy Burns
[attribution well and truly mangled at this point]
>>Well, given that their Win32 Common Driver model is going to be
>>incorporated with NT 5.0 so the driver code base between Win95 and
>>WinNT can be shared, I'd say the odds that the current HPFS driver
>>will work with the next version would be extremely unlikely.
>
>So all device drivers are going to have to rewritten? Didn't all
>video drivers have to be rewritten for 4.0 and now they have to change
>again?
Lets hope that this time round they force/allow addition of DPMS power down
support to the video drivers then ;-)
--
Andy Burns
an...@jabber.demon.co.uk
Byron Bodo
In article <59fm67$l03$2...@news3.microserve.net>, eti...@mail.microserve.net says...
>Actually, even with the lousy cache under Warp 3.0, HPFS still outperforms
>NTFS, because of all the "gizmos" built into it for file security and such.
>As far as warp 4.0, well, the HPFS cache is a hell of a lot better with read-
>ahead but a dynamic cache, shared with FAT and CDFS is what's really needed.
Gee. Is the vaunted NT dynamic cache anything like the win95 dynamic cache
that grabs all available ram, forces progs into swapping needlessly
& otherwise seems to produce no obvious benefits in disk i/o beyond
what accrue from setting a reaasonable fixed cache size?
-bb
ada...@io-online.com
>>> Other weird characteristics...NT has a *serious* file
>>It seems strange that NTFS would have serious file fragmentation
>>problems... pity. As for the disk cache, I've found even smartdrive
>>to perform better than the HPFS cache under OS/2. That, too, is a
>Actually, even with the lousy cache under Warp 3.0, HPFS still outperforms
>NTFS, because of all the "gizmos" built into it for file security and such.
>As far as warp 4.0, well, the HPFS cache is a hell of a lot better with read-
>ahead but a dynamic cache, shared with FAT and CDFS is what's really needed.
Couple notes: first, at work we have an NT machine. The NTFS partition is
*exactly* as fast as the FAT partition (less than 2% difference) using our
in-house benchmark suite. This is on a P150, so I doubt it's an overhead issue.
w/Warp4.0, increase the number of Worker threads and Lazy threads (with
your RUN=CACHE.EXE line in config.sys)
Also I found the cacheing problems were neatly side-stepped by getting a machine
with a 4MB intelligently cached RAID-0 controller. A bit pricey but *very* smooth.
I can copy an entire CD-ROM image from one partition to another in seconds. . .
krull
>
> Gee. Is the vaunted NT dynamic cache anything like the win95 dynamic cache
> that grabs all available ram, forces progs into swapping needlessly
> & otherwise seems to produce no obvious benefits in disk i/o beyond
> what accrue from setting a reaasonable fixed cache size?
>
But I wouldn't see it that bad. In most cases the cache of NT doesn't
grow undesirable huge. In NT Server you can chose different cache
strategys.
Ciao
Holger
jim frost
The NT cache management is actually quite sophisticated; about as
sophisticated as that of any UNIX system on the market.
I'm not going to try to explain all the details of the system here,
but if you have an application that needs to avoid losing its memory
to the cache it can make a simple system call to increase the working
set size allotted to your proces, effectively keeping those pages away
from the cache.
In any case NT 4.0 had algorithmic improvements such that the
thrashing behavior is rarely seen even on a system without explicit
tuning.
John Summerfield
In <32c04d8f.84028500@snoopy>, san...@inlink.com (Sangria) writes:
]On Tue, 17 Dec 1996 10:36:43 GMT, Illya Vaes <iv...@hr.ns.nl> wrote:
]>san...@inlink.com (Sangria) writes:
]>>Since NT 5.0 is going to have a different driver model than previous
]>>NT versions, it would make complete sense to do it before NT 5.0 if
]>And here I thought that NT 4.0 already had a new driver model (which is why
]>there were relatively little drivers and people were bitching about it, though
]>ofcourse "understanding" of the issue).
]Sure, every other OS that I can think of also changed driver models
]when they went from one version to the next.
On OS/2 earlier drivers are supported. I'm using an NE2000 driver
copyright MS. I imagine it was written for OS/2 1.2 or earlier.
While I'm using Warp Connect, i've also used the driver on Warp 4.
When IBM changes driver model (as they doo) it take care to ensure earlier
drivers are still supported.
Cheers
John Summerfield
Warped & Connected
Perth, Western Australia
OS2 support @ http://www.iinet.net.au/~summer
Unsolicited sales messages cost you $US1000
Vincent Taylor
In message <32be2...@news.io-online.com> - ada...@io-online.com23
Dec 96 06:29:45 GMT writes:
:>
:>w/Warp4.0, increase the number of Worker threads and Lazy threads (with
:>your RUN=CACHE.EXE line in config.sys)
BTW, just how do you set the thread numbers for read ahead and lazy
write workers? I tried "help cache" but there isn't mention of any
such options. TIA,
Vincent Taylor, Team OS/2
vta...@iglobal.net
Registered Shareware: Neologic Network Suite, PMMail, SpellGuard,
iLink, ZOC, FM/2, SIO, Workplace Shell Backup Utility, PlayBoy
CD Player, ScreenSaver, Taskbar, Workplace Security, PMView.
Please support OS/2 software and OS/2 by registering your
shareware.
Thore Harald Hoye
In article <59m32e$gl...@news.iglobal.net>,
vta...@iglobal.net (Vincent Taylor) wrote:
>BTW, just how do you set the thread numbers for read ahead and lazy
>write workers? I tried "help cache" but there isn't mention of any
>such options. TIA,
cache /?
--
Win95 - Beauty's only screen deep. [TEAM OS/2]