lkml.org 
[lkml]   [1998]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: mk2efs could format disk ??? (wa Re: LS-120 Formatting?)
Hello,

I do not wish to intrude but I hear people talking about fdformat
and I would like to remind you (and certain distribution vendors,
let's not name them (although it is Red Hat (and probably everyone
else) actually)), that
fdformat has been superceeded by superformat, which is a part of
fdutils package. And yes, it does make a difference which user space
software you use, because some do things right and others wrong.
E.g. I could not fdformat /dev/fd0 first thing after boot on IBM
ThinkPad while I was able to superformat /dev/fd0 without any problem.

Regards,
Tigran A. Aivazian, http://www.aivazian.demon.co.uk/

On Mon, 21 Dec 1998, Riley Williams wrote:

> Hi there.
>
> >>>>> Great. Now take 1.88Mb floppy (maked with xdfcopy) and explain
> >>>>> how to create standard 1.44Mb floppy with mkfs.ext2 :-))
>
> >>>> mke2fs /dev/fd0H1440
>
> >>> Yes, really ?
>
> >> Yep...
>
> > Try before claim such things. 1.88Mb format is NOT compatible with
> > any standard format on low level (there are 1K sectors to start
> > with :-).
>
> In that case, what 1.88M format are you using? The one I use uses 512
> byte sectors, the same as are used by all the other floppy formats
> that I use.
>
> If we're talking about different things, then naturally out results
> will differ...
>
> > So mk2efs will hanghs exactly the same way as in my experiment.
> > fdformat will work of course.
>
> Since your experiment turned out to be meaningless, so were its
> results...
>
> >>>>> Or even simpler: take 1.44Mb floppy and make 720Kb floppy from
> >>>>> it (this is safe).
>
> >>>> mke2fs /dev/fd0D720
>
> >>> Are you sure ? What about 5" 720K disks ? A have few 5" 1440Kb
> >>> disks and 720Kb disks :-))
>
> >> 5" 720k disks can be had with /dev/fd?h720 without problem. 5"
> >> 1440k disks are not one of the standard formats supported by
> >> Linux...
>
> > I have 5" 1440k disks and I'm could mount them as /dev/fd1H1440
> > just fine. mke2fs works with them just fine if I use /dev/fd1H1440
> > and does not work when I refer them as /dev/fd1h1200 !!! BTW 5"
> > 720k disks could be ACCESSED with /dev/fd?h720 but NOT CREATED from
> > 360k or 1.2M disks not via fdformat /dev/fd?h720 nor with mke2fs
> > /dev/fd?h720 !!! Both commands will just hungs !
>
> Curious that, wonder what you're doing wrong...
>
> >> Incidentally, my understanding as to why these work when using
> >> /dev/fd0 doesnae is because the suffixed versions over-ride the
> >> drive's own details and return their own...
>
> > Yes, suffixed version just says: "no, autodect will fail for this
> > drive -- do not try it". Suffixed version could not magically
> > reformat drive (fdformat could and here suffixed versions are
> > helpful since autodetect will fail here :-) but could just say to
> > kernel: "no there are not 18 sectors for track but only 9". Kernel
> > will happily use only 9 first sectors then. Floppy will look like
> > 720K floppy afterwards but still there are will be 18 sectors for
> > each track (9 of them not used). This is not a case for 1.88Mb
> > drive vs 1.44Mb drive (different sector sizes) nor for 1.2Mb drive
> > vs 360K drive (different number of tracks).
>
> Ah...that makes sense...
>
> >>>> I regularly do the latter, and have never had any problems with
> >>>> it...
>
> >>>>> Again format under DOS will do this just fine.
>
> >>>> Again, why bother with DOS ???
>
> >>> Since in DOS low-level format and filesystem creation is combined
> >>> in one program unlike Linux.
>
> >> True, but irrelevant...
>
> > VERY RELEVANT -- see below. DOS format could change format of media
> > if needed. mke2fs COULD NOT ! NEVER ! Interpretation of format for
> > already formatted media could be changed (sometimes successfull,
> > sometimes not) but reformating will NEVER occurs.
>
> I've now triple-checked, and I found some curious results...
>
> 1. 1.44M disk formatted as 720k with "mkdosfs /dev/fd0D720" is, as
> you state, actually formatted with 18 sectors per track, but
> only 9 of them used. However, Win95 has no problem using it as
> a 720k disk in that format.
>
> 2. 1.2M disk formatted as 720k with "mkdosfs /dev/fd0h720" is also
> formatted as 15 sectors per track with only 9 of them used, but
> in this case, Win95 is NOT able to use the resulting disk.
>
> 3. 1.2M disk formatted as 360k with "mkdosfs /dev/fd0d360" fails
> to format.
>
> I therefore stand corrected regarding my belief that mke2fs and
> mkdosfs were reformatting the disk completely, having been fooled by
> case (1) above, and I thus apologise for the resultant misleading
> comments...
>
> However, I do NOT apologise for the rest of my comments, which were
> apparently due to the two of us talking about different things...
>
> >>>> For reference, from this system:
>
> >>> Q>> $ ls -lFG /dev/fd0*
> >>> Q>> brw-rw-r-- 1 root 2, 0 May 5 1998 /dev/fd0
> >>> Q>> brw-rw-r-- 1 root 2, 12 May 5 1998 /dev/fd0D360
> >>> Q>> brw-rw-r-- 1 root 2, 16 May 5 1998 /dev/fd0D720
> >>> Q>> brw-rw-r-- 1 root 2, 28 May 5 1998 /dev/fd0H1440
> >>> Q>> brw-rw-r-- 1 root 2, 12 May 5 1998 /dev/fd0H360
> >>> Q>> brw-rw-r-- 1 root 2, 16 May 5 1998 /dev/fd0H720
> >>> Q>> brw-rw-r-- 1 root 2, 4 May 5 1998 /dev/fd0d360
> >>> Q>> brw-rw-r-- 1 root 2, 8 May 5 1998 /dev/fd0h1200
> >>> Q>> brw-rw-r-- 1 root 2, 20 May 5 1998 /dev/fd0h360
> >>> Q>> brw-rw-r-- 1 root 2, 24 May 5 1998 /dev/fd0h720
> >>> Q>> $
>
> >>> Ok. Just tried to use your braindead "theory" :
>
> > RW> ===8<=== Lots more rubbish omitted, relevant lines retained ===>8===
>
> >>> [root@localhost /root]# fdformat /dev/fd1h1200
> >>> [root@localhost /root]# mke2fs /dev/fd1h360
>
> >>> RedHat 5.1, /dev/fd1 -- 5" floppy drive, more information available
> >>> by request.
>
> >>> Why mke2fs works just fine after fdformat /dev/fd1h360 but not
> >>> after fdformat /dev/fd1h1200 ?
>
> >> Probably because those two are NOT compatible with each other.
>
> > Yes. It was EXACTLY what I'm want: two DIFFERENT, INCOMPATIBLE
> > formats but for the same physical media ! This is needed as
> > countersample for your stupid theory about magic format while
> > mke2fs ...
>
> Isn't it a pity the two you chose are NOT for the same physical media.
> The former is defined SPECIFICALLY for 3.5" floppies, the latter for
> 5" floppies, and whilst they behave identically on many systems, ON
> SOME THEY DO NOT!!!
>
> I have known for some considerable time that on two of my systems,
> /dev/fd0h360 and /dev/fd1d360 work fine, but /dev/fd0d360 and
> /dev/fd1h360 both fail, and on all the rest, all four will work quite
> happily.
>
> >> Try using the compatible options, which have been working fine for
> >> me for OVER TWO YEARS...and if they're not working for you, then
> >> either you've patched the kernel to prevent them from doing so,
> >> somebody else has done so, or the relevant entries in /dev have
> >> the wrong mknod numbers attached to them...
>
> > Yes, I know. But this will not prove ANYTHING about initial claim
> > !!! If there are compatible options then reformating is not needed !
>
> If they are HARDWARE-INCOMPATIBLE options like you chose, then you
> prove absolutely nothing, as you succeeded in doing above...
>
> >> For reference, your second line should refer to
>
> > Q>> /dev/fd1d360
> > Q>> ^
>
> >> As I understand it, /dev/fd1h360 refers to a drive formatted as
> >> SINGLE sided, 80 tracks, 9 sectors per track, but I have never
> >> found a drive where it could be used...
>
> > You are joking. Yet again:
> > -- cut --
> > [root@localhost /root]# fdformat /dev/fd1h360
> > Double-sided, 40 tracks, 9 sec/track. Total capacity 360 kB.
> > Formatting ... done
> > Verifying ... done
> > -- cut --
>
> I have to admit that was a bit of a wind-up, to see whether you were
> as easily midled as you were pretending, and I'm glad to report that
> you're not...
>
> Incidentally, MS-DOS 3.10 was quite happy to use both 3.5" and 5.25"
> disks formatted to the specifications I gave above, and the MS-DOS
> format command could even be told to create them, but Linux has never
> (as far as I know) included support for them...
>
> For some reason, MS-DOS 5.00 and later's format command refuses to use
> that format...
>
> > What's the difference between /dev/fd?h360 and /dev/fd?d360 ??? You
> > are joking ! This is just mean: high-density floppy formatted for
> > 360k and double-density drive formatted for 360k !!! (Why the
> > difference ? Oh. Long story. There are difference in coercive force
> > for different types of floppies :-)
>
> There's more of a difference than that, as my experience has shown.
> No, I don't know what the other differences are, but they clearly
> exist...
>
> > Just standard 2.0.34 kernel from RedHat 5.1 (I'm use some 2.1.x
> > kernel usually but specially for testing I'm reboted with this old
> > one :-)
>
> No problem. I'm using 2.0.36 myself, having upgraded RedHat 5.1 a
> while back...
>
> > Here was you point: mk2efs could format drive. This is HORRIBLE
> > wrong.
>
> As stated above, I accept that I was wrong about this, having been
> misled by some curious anomolies in the way Linux does things...
>
> > I am have physical media (5" disk :-) which could be formatted by
> > two different incompatible low-level format versions: as h1200 and
> > as h360 (d360 will work as well -- just information will be kept
> > safely on disk for less time :-).
>
> As stated above, fd?d360 and fd?h360 are NOT always identical, hence
> my querying your use of (to me) hardware incompatible formats...
>
> > If mk2efs could format media (this was your initial claim and start
> > of discussion) then this should not lead to any problems.
>
> As stated above, I was wrong here, and I apologise for it...
>
> > This is not a case: if disk is formatted as h360 (via fdformat)
> > mke2fs works, if disk is formatted as h1200 (via fdformat) then
> > mke2fs hangs horrible. What this means ? Just one thing: mke2fs
> > will not format disk ! NEVER !
>
> Fair enough, although you may find my comments earlier in this missive
> of interest...
>
> Best wishes from Riley.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.084 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site