At 09:35 27/03/2001, Ion Badulescu wrote:
>Compile option or not, 64-bit arithmetic is unacceptable on IA32. The
>introduction of LFS was bad enough, we don't need yet another proof that
>IA32 sucks. Especially when there *are* better alternatives.
Sorry, but why should it be unacceptable? It works, so what's the problem?
I would much rather have a performance hit, than have it not working at
all. I am definitely putting 64-bit arithmetic into the new NTFS project as
most of NTFS is 64-bit, and I find it quite acceptable. So it will be a few
% slower than with 32-bit, but it will also mean that it will actually
work, rather than just refusing to mount or crashing out half-way through
complaining about 64-bit sizes not being implemented, or even worse,
crashing the kernel / causing fs data corruption due to overflows.
With the current trend in HD prices, I will probably have TiB storage on my
32-bit CPU PC within a few years (at the moment I am at 0.1TiB), and no, I
am not going to upgrade my computers to 64-bit ones for large amounts of
money, when I can just buy a (few) cheap new disk(s).
Anyway, what is this obsession with speed? Surely it is stability, and
capability which is more important than speed? I don't care whether my PC
scores top on every benchmark or not, but I do care that my PC can do
everything I want it to do, in this case use large hds.
I see the point why people with small systems would not want 64-bit, so I
agree that a compile time option is a good idea. Where is your problem with
that? If you find 64-bit maths on ia32 unacceptable, then just don't use
it! Your kernel will just have a few features less. On the other hand, for
those of us, who do think it is acceptable, we can enable it and enjoy the
features we want.
Windows NT uses 64-bit maths all the way through NTFS and it works fine. I
don't see my fs being slow, and in about 4 years of use, I have only ever
had one problem with fs-corruption caused by NT. Unacceptable? I think not.
I think you are forgetting that 64-bit maths is still on the CPU, which is
fast, I/O speed is bound by the HD, not by the CPU, so whether the fs-code
is a bit slower or not will not make any difference in the actual disk
access case. (Cache access is of course a different matter.)
Just my 2p.
Regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
