9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Alexander Viro <viro@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] New to Plan9
Date: Sat, 26 Aug 2000 16:23:03 -0400	[thread overview]
Message-ID: <200008262023.QAA01437@weyl.math.psu.edu> (raw)
In-Reply-To: <200008231430.KAA27086@cse.psu.edu>

In article <200008231430.KAA27086@cse.psu.edu> you write:
>As for the 486 it sounds like more floppy problems
>(something is amiss in the floppy driver, but no
>one is sure what).  I don't understand why having
>an old floppy drive under Linux would mean you 
>can't mount disks of type vfat or ext2.  I don't
>know what tricks ext2 pulls, but vfat should be 
>using the same bits as fat does, i.e. the standard
>1.44MB of data.

ext2 is a garden variety FFS. It could not care less about the media or
geometry - all accesses go through getblk() and bread() (or pagecache
equivalents in 2.4) and it simply doesn't know anything about the
underlying device.

There are some _very_ sick tricks used by deranged DOS format(8) variants.
Resulting diskette
	a) has different physical format on the first track and on the
rest of the disk (the first track is shorter, usually 18 sectors vs.
30 or so)
	b) contains filesystem thinking that the first track has the same size
as everything else (otherwise DOS would barf and die)
	c) relies on the fact that fatfs has reserved area it never touches.
That reserved area is actually not present - it would live in the end of the
first track if that track would have the same size as everything else.

It works under DOS because DOS uses 3D addressing and never asks for the
blocks in the end of first track. Linux floppy driver tries to cope with
such horror when it meets one, but the best it can do is to refuse serving
the requests for blocks in that "hole" - if it would just map the block 18
to the beginning of the second track fatfs would die, because it expects
block 30 there. E.g. dd(1) will be very unhappy. IMO we shouldn't support
that mess at all - yes, it's impossible to deal with from userland, but
anyone dumb enough to use 2m and its ilk deserves to lose.

That's the only case when ability to use the disk will depend on fs in
question and it's _really_ not something you want to support. _If_ the
diskettes with problems are in 2m format - just tell user to sod off or
to do normal lowlevel format. Frankly, we should do the same, but maintainer
of floppy driver has some strange ideas about being nice to lusers.

It it's not a 2m perversion and Linux can do one fs type but not another -
send the bug report.

-- 
Fairy Tails start "Once upon a time."
Army/Sea stories start "This is no shit."
Software proposals start "1.0."
				Joe Zeff in the Monastery


  reply	other threads:[~2000-08-26 20:23 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-23 14:29 Russ Cox
2000-08-26 20:23 ` Alexander Viro [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-10-15 12:53 [9fans] New to plan9 joseph turco
2021-10-15 13:05 ` Sigrid Solveig Haflínudóttir
2021-10-15 14:07   ` sirjofri
2021-10-15 17:29     ` joseph turco
2021-10-15 17:45       ` Michael Misch
2021-10-15 18:36         ` joseph turco
2021-10-15 18:56           ` hiro
2021-10-15 21:00             ` joseph turco
2021-10-16 10:13               ` Keith Gibbs
2021-10-16 12:35                 ` Mart Zirnask
2021-10-16 14:08                   ` Conor Williams
2021-10-16 19:07                     ` joseph turco
2021-10-16 19:11                       ` hiro
2021-10-17 18:54                         ` antonio.fin
2021-10-18 16:26                           ` joseph turco
2021-10-19 17:46                             ` antonio.fin
2021-10-19 21:27                               ` Michael Misch
2021-10-20 15:50                                 ` joseph turco
2021-10-20 16:03                                   ` Sigrid Solveig Haflínudóttir
2021-10-20 16:46                                     ` joseph turco
2021-10-20 16:56                                       ` Sigrid Solveig Haflínudóttir
2021-10-20 17:06                                         ` joseph turco
2021-10-20 17:14                                           ` Sigrid Solveig Haflínudóttir
2021-10-20 18:44                               ` Skip Tavakkolian
2021-10-20 21:55                                 ` joseph turco
2021-10-16  2:45     ` vic.thacker
2021-10-15 15:54 ` smj
     [not found] <e_n_d_e_r@hotmail.com>
2000-08-23  9:10 ` [9fans] New to Plan9 Roy Miller
2000-08-23 15:29   ` James A. Robinson
2000-08-24  8:35     ` Douglas A. Gwyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200008262023.QAA01437@weyl.math.psu.edu \
    --to=viro@math.psu.edu \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).