vfat32 supported in Linux?
Lim Chee Siang
I beg your pardon if this question has been asked before. But can anyone
please tell me if vfat32 is supported in Linux 2.0.xx ? If not, is there
any way I can patch it to support vfat32.
I am now using Linux 2.0.28, and Win95. I intend to overwrite the
original Win95 with the oem version. Any comment?
Thanks
--
._,.--._, ___
.-" _. -.~"--~ ~-. ._--------------------------------\
/ .-" Y _\. \ / Nowadays real estate is so hot, |
Y ! ~: Y / this space is open for bidding /
|. \ | q pl / as well! BTW, I have taken up /
L| \ l ,-. ./ _\ most of the space here!! /
! ;"\_/ \| )___/()\-------------------------------
\. ./~ . /~-.____./
T ~"rv". _Y _Y In case you want to know, my real name
L j| ( ) is Lim Chee Siang with eng4...@nus.sg or
[..nn[].n.n[nn] cs...@eeserver.ee.nus.sg, or 65-7752544.
George Lebl
On 13 Feb 1997 04:07:01 GMT, Lim Chee Siang <eng4...@leonis.nus.sg> wrote:
>I beg your pardon if this question has been asked before. But can anyone
>please tell me if vfat32 is supported in Linux 2.0.xx ? If not, is there
>any way I can patch it to support vfat32.
>
>I am now using Linux 2.0.28, and Win95. I intend to overwrite the
>original Win95 with the oem version. Any comment?
it is supported AND ... you need to get a driver .. i think it's in beta
.. or alpha .... but it's said to work ok ...
go to http://www.ecsnet.com ... and go to their linux related links
section .. i know it's there ....
George
--
--------------------------------------------------------------------------------
Sex Pistols RULE!!! fr...@azstarnet.com
George Lebl
On 13 Feb 1997 04:07:01 GMT, Lim Chee Siang <eng4...@leonis.nus.sg> wrote:
>I beg your pardon if this question has been asked before. But can anyone
>please tell me if vfat32 is supported in Linux 2.0.xx ? If not, is there
>any way I can patch it to support vfat32.
>
>I am now using Linux 2.0.28, and Win95. I intend to overwrite the
>original Win95 with the oem version. Any comment?
anyway .. I read in the specs that fat32 is actually slower then the
normal fat ... just curious .. what's the real advantage of this
filesystem ... I heard they finally figured out how to put more files in a
directory instead of that .. allyourfilesinonebigfile thing ... I never
got the rationell of M$ putting so many files in /windows and
/windows/system ... when they knew about this problem ... and it's one of
the most painful slowdowns .. especially on boot ... they knew this was a
problem .. why not introduce more directories, try to sort it out ... keep
files in a single dir to a minimum .. well that's beyond me ... it's also
why apps that have their dll in their own private dir load faster then
those which have them in the system/ dir ... which kind of beats the dll
concept for me ... if each app has it's own copy ???? ... I remember MS
making two diff versions of THREED.VBX ... and I wrote a program that used
the (older) one and it didn't work on about 50% of teh systems ... I had
to rewrite the install to overwrite even newer copies of the threed.vbx
.... though this potentially broke other programs ... (well i allways
though VB was a nice scripting language, and that program we were porting
from PowerBasic ... before TurboBasic .. and even before that it was
written on a Speccy ... so it has a long history of being written in
basics ... and the routines are still the original :)
man .. i'm rambling again ... and off topic too ...
SHUT UP GEORGE ...
actually something to the topic .. do you know if lpd got broke in newer
kernels ... it might also be the libc which i upgraded ...
and another thing ... I know this was a while ago but how about putting
the joystick driver in the kernel .. since that way it will keep up with
times faster ... and when i was a new linux user it took me quite a while
to find it ... the joystick driver 0.8.0 is stable .. and i posted the
patch for it to run on 2.1.x kernels a while ago ... i think it would be
more stable then most patches that go into the development kernels ...
how bout it
and yes my grammar and spelling and notcapitalizing sux .. so i'm sure to
get a bunch of ... you spelled this and that wrong messges :)
Uwe Bonnes
Lim Chee Siang <eng4...@leonis.nus.sg> wrote:
: I beg your pardon if this question has been asked before. But can anyone
: please tell me if vfat32 is supported in Linux 2.0.xx ? If not, is there
: any way I can patch it to support vfat32.
Well, I don't give you pardon :-) (and a little :-( )
It has been asked many time before. Why
don't you search with e.g.http://www.dejanews.com for "linux fat32".
It would sure bring up
http://bmrc.berkeley.edu/people/chaffee/fat32.html
--
Uwe Bonnes b...@elektron.ikp.physik.th-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Paul Garceau
On 13 Feb 1997 04:07:01 GMT, the Illustrious eng4...@leonis.nus.sg
(Lim Chee Siang) wrote:
>I beg your pardon if this question has been asked before. But can anyone
>please tell me if vfat32 is supported in Linux 2.0.xx ? If not, is there
>any way I can patch it to support vfat32.
As far as I know, vfat is 32bits. Kernel configuration for 2.0.x
has an option to enable vfat under the fs selection menu/options. the
vfat fs is recommended, according to the readme documentation, if you
wish to access Win95 stuff.
Paul G.
Jurgen Exner
Because vfat32 doesn't exist there is no support for it in Linux.
But there is support for
vfat: standard in all recent kernels
fat32: see http://bmrc.berkeley.edu/people/chaffee/fat32.html for a driver
jue
--
The opinions expressed in this message are my own personal views
and do not reflect the official views of Microsoft Corporation
Lim Chee Siang <eng4...@leonis.nus.sg> wrote in article
<5du415$5...@nuscc.nus.sg>...
> I beg your pardon if this question has been asked before. But can anyone
> please tell me if vfat32 is supported in Linux 2.0.xx ? If not, is there
> any way I can patch it to support vfat32.
>
> I am now using Linux 2.0.28, and Win95. I intend to overwrite the
> original Win95 with the oem version. Any comment?
>
George Lebl
On Thu, 13 Feb 1997 11:31:26 GMT, Paul Garceau <pa...@teleport.com> wrote:
>>I beg your pardon if this question has been asked before. But can anyone
>>please tell me if vfat32 is supported in Linux 2.0.xx ? If not, is there
>>any way I can patch it to support vfat32.
>
>has an option to enable vfat under the fs selection menu/options. the
>vfat fs is recommended, according to the readme documentation, if you
>wish to access Win95 stuff.
vfat isn't fat32 ... fat32 is a new system, unlike vfat which is still
kind of the old one ... it's just long filenames on top of fat ...
Gordon Chaffee
In article <slrn5g5ebk...@rotten.com>,
George Lebl <fr...@azstarnet.com> wrote:
>>I am now using Linux 2.0.28, and Win95. I intend to overwrite the
>>original Win95 with the oem version. Any comment?
You should be OK. Get the patch from
http://bmrc.berkeley.edu/people/chaffee/fat32.html
>anyway .. I read in the specs that fat32 is actually slower then the
>normal fat
I don't know where you read this info. For large disks, it might be
faster, particularly where you have a small disk cache. On laptops
disks, where the cache may be only 50 or 75KB, a 32KB fat16 cluster
on a large partition (i.e over 520MB), will fill up most of the disk
cache. If you are reading a series of small files, fat32 should be
faster. Other than that, I don't see a significant difference.
> ... just curious .. what's the real advantage of this filesystem
If you read the specs, you should see. The main advantage is much
less wasted space. I might have a link on the above page to the
specs..
> ... I heard they finally figured out how to put more files in a
>directory instead of that .. allyourfilesinonebigfile thing ... I never
>got the rationell of M$ putting so many files in /windows and
>/windows/system
If you mean the filesystem is more efficient in terms of the the
directory structure, nothing has changed.
--
Gordon Chaffee
cha...@bmrc.berkeley.edu
http://bmrc.berkeley.edu/people/chaffee
Alain Knaff.DELETE.THIS
In <5dvrl9$b...@agate.berkeley.edu>, Gordon Chaffee <cha...@odie.CS.Berkeley.EDU> wrote:
:> ... I heard they finally figured out how to put more files in a
:>directory instead of that .. allyourfilesinonebigfile thing ... I never
:>got the rationell of M$ putting so many files in /windows and
:>/windows/system
:
:If you mean the filesystem is more efficient in terms of the the
:directory structure, nothing has changed.
Maybe George means the root directory... But then he mentions
directories such as \windows... Oh well.
--
Linux - Why use Windows, since there is a door?
Alain
M. Buchenrieder
pa...@teleport.com (Paul Garceau) writes:
>On 13 Feb 1997 04:07:01 GMT, the Illustrious eng4...@leonis.nus.sg
>(Lim Chee Siang) wrote:
>>I beg your pardon if this question has been asked before. But can anyone
>>please tell me if vfat32 is supported in Linux 2.0.xx ? If not, is there
>>any way I can patch it to support vfat32.
> As far as I know, vfat is 32bits. Kernel configuration for 2.0.x
>has an option to enable vfat under the fs selection menu/options. the
>vfat fs is recommended, according to the readme documentation, if you
>wish to access Win95 stuff.
This will NOT work with FAT32 partitions. Indeed, this might even ruin
your FAT32 partition. You'll need to get the driver for FAT32 from
http://bmrc.berkeley.edu/people/chaffee/fat32.html
Michael
--
Michael Buchenrieder * mi...@scrum.muc.de / mi...@scrum.greenie.muc.de
**************************************************************************
Portable, adj.:
Survives system reboot.
George Lebl
On 13 Feb 1997 19:56:25 GMT, Gordon Chaffee <cha...@odie.CS.Berkeley.EDU> wrote:
>>anyway .. I read in the specs that fat32 is actually slower then the
>>normal fat
>
>I don't know where you read this info. For large disks, it might be
>faster, particularly where you have a small disk cache. On laptops
>disks, where the cache may be only 50 or 75KB, a 32KB fat16 cluster
>on a large partition (i.e over 520MB), will fill up most of the disk
>cache. If you are reading a series of small files, fat32 should be
>faster. Other than that, I don't see a significant difference.
the official micro$oft page (the fat32 page points to that) .. states that
it will be slightly slower ...
>> ... just curious .. what's the real advantage of this filesystem
>
>If you read the specs, you should see. The main advantage is much
>less wasted space. I might have a link on the above page to the
>specs..
well i could see a less wasted space argument a few years ago when hard
disks were expensive, now i would see, speed, reliablity and flexibility
as more of an argument for a new filesystem. from what I read fat 32
should be slightly more reliable but about as flexible as the last fat ...
>> ... I heard they finally figured out how to put more files in a
>>directory instead of that .. allyourfilesinonebigfile thing ... I never
>>got the rationell of M$ putting so many files in /windows and
>>/windows/system
>
>If you mean the filesystem is more efficient in terms of the the
>directory structure, nothing has changed.
well then .. see my point above ??? ... I can't see why they are putting
out a new filesystem which will break so many things ... mainly ther is a
posibility of converting fat16 to fat32 but m$ has no plans to do such a
program (in the near future that is) ...
so there's still the limit on the number of files in a single
directory???? hmm ...
I can't see why .. if they are designing a non-compatible filesystem
anyway ... don't they try to do something that would add a lot ... once
thing i could see they should add is some of unix features to dos
filesystems ... and teh possibility of virtual drives, symlinks,
ownership, permissions (NTFS has that in some form or other, so they
could just improve on NTFS instead of improving on FAT16)
not that I really care since I lost interest in the M$ world long ago ...
I have a dos/nt partition running on FAT16 in case i get bored of
stability and want to see a system crash :) I can say NT has crashed for
me only once for the last 3 months or so .. the reason probably is I ran
it about 3-4 times :) ... I ran dos more frequent for games though ...
George Lebl
On 14 Feb 1997 20:12:36 GMT, Alain Knaff.DELETE.THIS <~Alain...@poboxes.com> wrote:
>:If you mean the filesystem is more efficient in terms of the the
>:directory structure, nothing has changed.
>
>directories such as \windows... Oh well.
I though it was meant for others then root too ???? it wasn't ... hmm ...
Egbert Hinzen
George Lebl <fr...@azstarnet.com> wrote:
> >If you read the specs, you should see. The main advantage is much
> >less wasted space. I might have a link on the above page to the
> >specs..
> well i could see a less wasted space argument a few years ago when hard
> disks were expensive, now i would see, speed, reliablity and flexibility
> as more of an argument for a new filesystem. from what I read fat 32
> should be slightly more reliable but about as flexible as the last fat ...
Changing the FS on a 2 GB HD gave me more the 500 MB back.
*I* think that's an argument.
Now it's possible to handle partitions > 2 GB.
That's an other.
--
Egbert Hinzen
SUNSOFT Buero und EDV GmbH, Cologne, Germany
*** PGP Public Key (ID: 16D8A675) available at PGP-Key-Servers.
*** Don't use any of my keys released before 1997.
Joseph Foley
On 15 Feb 1997 04:36:05 GMT, George Lebl <fr...@azstarnet.com> wrote:
>
>I can't see why .. if they are designing a non-compatible filesystem
>anyway ... don't they try to do something that would add a lot ... once
>thing i could see they should add is some of unix features to dos
>filesystems ... and teh possibility of virtual drives, symlinks,
>ownership, permissions (NTFS has that in some form or other, so they
>could just improve on NTFS instead of improving on FAT16)
Well, microsoft isn't really in the DOS business anymore. If they wanted
NTFS, they would have had to integrate the NTFS code into the real mode
"DOS" 7.0 kernel that win95 uses to boot. Not a task I would want to take on.
>not that I really care since I lost interest in the M$ world long ago ...
>I have a dos/nt partition running on FAT16 in case i get bored of
>stability and want to see a system crash :) I can say NT has crashed for
>me only once for the last 3 months or so .. the reason probably is I ran
>it about 3-4 times :) ... I ran dos more frequent for games though ...
>
NT 3.51 was stable for me. 4.0 is questionable for me. And it's a bitch
working on custom drivers and hardware when a bootup takes almost 4 minutes
on a PPro 200 w/ 64 MB.
Joseph
George Lebl
On Sat, 15 Feb 1997 23:07:21 GMT, Egbert Hinzen <egb...@garfy.ehinzen.com> wrote:
>> well i could see a less wasted space argument a few years ago when hard
>> disks were expensive, now i would see, speed, reliablity and flexibility
>> as more of an argument for a new filesystem. from what I read fat 32
>> should be slightly more reliable but about as flexible as the last fat ...
>
>Changing the FS on a 2 GB HD gave me more the 500 MB back.
>*I* think that's an argument.
>Now it's possible to handle partitions > 2 GB.
>That's an other.
hmmm .. even when a computer i'm installing on has a large harddrive .. it
seems to me very logical to partition it anyway ... having everything
under one drive makes it more messy .. so I never had this problem ...
since all my fat partitions (there were 4 at one time :) were about 500
meg ...
I didn't say it want a problem with fat ... and i think it's probably
better then fat16 (hmmm ... what isn't) ... though i have no great need
for a fat partition (except for quake, which does run faster on dos :)
the point i was making .. if they are already designing a new filesystem
.. i don't see this as the MAIN trouble ... since there are simpel ways
around it that don't hurt anything (make more partitions) ... There are
many more problems with fat that aren't solved (as far as i have read the
specs)
there was a post day ago or so that it was microsoft's strategy to make
people switch to NT's ... I think that might be it ... make Win97 a flop
that way ... since people already have a bunch of NT/95 apps which don't
run on anything else ... will have to buy NT's
well whatever ... i'm not gonna use fat32 ... i will keep my fat16
partitions for dos and be happy with it for another few months/years
before getting really pissed and nuking both NT and dos ... I had 95's
installed for about a month, I booted it twice before nuking it ... so
NT's can't last that long ... (only dos will survive, I'll prolly get
opendos to see if it can run quake:)
Alain Knaff.DELETE.THIS
In <slrn5gafl2...@rotten.com>, George Lebl <fr...@azstarnet.com> wrote:
:On 14 Feb 1997 20:12:36 GMT, Alain Knaff.DELETE.THIS <~Alain...@poboxes.com> wrote:
:>:If you mean the filesystem is more efficient in terms of the the
:>:directory structure, nothing has changed.
:>
:> Maybe George means the root directory... But then he mentions
:>directories such as \windows... Oh well.
:
:I though it was meant for others then root too ???? it wasn't ... hmm ...
:
:George
In FAT12 and FAT16, the root directory used to be at a fixed location
at the beginning of the disk, and had a fixed length. Subdirectories
never had such a restriction: they could contain as many files as they
wanted, and could be moved accross the disk by defragmenters for more
efficiency.
Now, in FAT32, the root directory has a variable length as well.
George Lebl
On 16 Feb 1997 08:35:49 GMT, Alain Knaff.DELETE.THIS <~Alain...@poboxes.com> wrote:
>:I though it was meant for others then root too ???? it wasn't ... hmm ...
>
>at the beginning of the disk, and had a fixed length. Subdirectories
>never had such a restriction: they could contain as many files as they
>wanted, and could be moved accross the disk by defragmenters for more
>efficiency.
hmm didn't know that ... although i tested it and with about 100-150 files
in a subdir the performace goes down QUITE A LOT ... could be then just
the software (standard msdos commands)
Alain Knaff.DELETE.THIS
In <slrn5geq7...@rotten.com>, George Lebl <fr...@azstarnet.com> wrote:
:On 16 Feb 1997 08:35:49 GMT, Alain Knaff.DELETE.THIS <~Alain...@poboxes.com> wrote:
:>:I though it was meant for others then root too ???? it wasn't ... hmm ...
:>
:> In FAT12 and FAT16, the root directory used to be at a fixed location
:>at the beginning of the disk, and had a fixed length. Subdirectories
:>never had such a restriction: they could contain as many files as they
:>wanted, and could be moved accross the disk by defragmenters for more
:>efficiency.
:
:hmm didn't know that ... although i tested it and with about 100-150 files
:in a subdir the performace goes down QUITE A LOT ... could be then just
:the software (standard msdos commands)
Actually, the changes were not about efficiency at all... only about
maximal possible size. For instance, you usually could not have more
than 512 root directory entries on a FAT16 harddisk (this values are
settable at format time, but 512 is the default). Of course,
efficiency (search time) will go down the more actual entries are
contained in the directory, whether root or not, whether FAT16 or
FAT32.
Most filesystems (even Linux') are subject to this decrease in
performance, except OS/2's HPFS filesystem, which uses binary trees
for directory lookup instead of a linear search.
George Lebl
On 16 Feb 1997 21:58:26 GMT, Alain Knaff.DELETE.THIS <~Alain...@poboxes.com> wrote:
> Most filesystems (even Linux') are subject to this decrease in
>performance, except OS/2's HPFS filesystem, which uses binary trees
>for directory lookup instead of a linear search.
at one time having around 200 files in my home dir (before cleaning:) ...
it read any file so fast i couldn't notice a difference ... the access
time in dos to some files in directories with 150+ files is ridiculous ...
I used to do CoreWar evolution and had a C program managing a whole bunch
of files ... actually a 100 directories of 10 or 100 files each ... with
10 it wen't ok under dos and unix ... with 100 it was slower but not as
much on unix .. only about 11 or so times .. under dos it was more like 50
times slower then with 10 files a dir ... if it's not the filesystem are
dos tools just really inefficent with directories which have a lot of
files ...
Todd Graham Lewis
On 17 Feb 1997, George Lebl wrote:
> On 16 Feb 1997 21:58:26 GMT, Alain Knaff.DELETE.THIS <~Alain...@poboxes.com> wrote:
> > Most filesystems (even Linux') are subject to this decrease in
> >performance, except OS/2's HPFS filesystem, which uses binary trees
> >for directory lookup instead of a linear search.
>
> at one time having around 200 files in my home dir (before cleaning:) ...
> it read any file so fast i couldn't notice a difference ... the access
> time in dos to some files in directories with 150+ files is ridiculous ...
It's ridiculous under Unix, too, when you're really using the file
system. A mail spool with 150,000 files in it comes to mind.
There was an interesting USENIX paper a few years (??) ago about their
file system which uses a database-style indexing method. It looked pretty
neat, but the details escape me right now.
__
Todd Graham Lewis Linux! Core Engineering
Mindspring Enterprises tle...@mindspring.com (800) 719 4664, x2804
Franz
> > at one time having around 200 files in my home dir (before cleaning:) ...
> > it read any file so fast i couldn't notice a difference ... the access
> > time in dos to some files in directories with 150+ files is ridiculous ...
>
> It's ridiculous under Unix, too, when you're really using the file
> system. A mail spool with 150,000 files in it comes to mind.
at least under unix the time vs. #of files is a linear relation .... or
seems like it ... if it's scanning the dirs linearly it's quite a logical
assumption :) ... under dos this seems to be quite a jump .. maybe it
grows exponentialy ...:) I allways credited this to how fat is done ...
> There was an interesting USENIX paper a few years (??) ago about their
> file system which uses a database-style indexing method. It looked pretty
> neat, but the details escape me right now.
how about creating a new fs for linux, ext2 alike but faster somewhat like
hpfs+ext2 ... I know hpfs takes a lot on the disk but me being a speed
freak i don't care :) ... i don't know about filesystems but searching
linearly seems to be the worst way there is .... or at least that's what
they tell you in every book you read .... n sucks ... log(n) is much
better :)
George
George Lebl
On 15 Feb 1997 07:19:05 GMT, Joseph Foley <jfo...@h57.fulton.albany.edu> wrote:
>Well, microsoft isn't really in the DOS business anymore. If they wanted
>NTFS, they would have had to integrate the NTFS code into the real mode
>"DOS" 7.0 kernel that win95 uses to boot. Not a task I would want to take on.
well if they are gonna dump win95 anyway ... why not just leave it at
fat16 .. which is something that stuff works on instead fo creating a new,
temporary and incompatible filesystem .... I don't get the good bussines
part of it ... if it offers no performance or some actually visible new
features ... why do it at all ...
>>not that I really care since I lost interest in the M$ world long ago ...
>>I have a dos/nt partition running on FAT16 in case i get bored of
>>stability and want to see a system crash :) I can say NT has crashed for
>>me only once for the last 3 months or so .. the reason probably is I ran
>>it about 3-4 times :) ... I ran dos more frequent for games though ...
>
>NT 3.51 was stable for me. 4.0 is questionable for me. And it's a bitch
>working on custom drivers and hardware when a bootup takes almost 4 minutes
>on a PPro 200 w/ 64 MB.
yeah .... get the 3rd path from ms that's the most stable one ...