Ok, first off I'd like to say, I am on 2.6.12-rc3-mm2, and this issue
is not fixed at all. Secondly, I'd like to say that I've pinpointed
it a bit more. It appears only Empty partitions (type 0 in fdisk) do
not create device nodes.
Here is the partition table from fdisk, fdisk does run fine.. its just
the fact this node is not created that threw me off before.
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 2 16033+ 0 Empty
/dev/sdb2 * 6 2431 19486845 b W95 FAT32
/dev/sdb3 3 5 24097+ 83 Linux
Notice, /dev/sdb1 is a Empty partition... in /dev I only have sdb,
sdb2, and sdb3. No sdb1. Any help would be appreciated.
Thanks,
Joe
On Mon, May 02, 2005 at 10:51:24PM -0400, Joe wrote:
> Ok, first off I'd like to say, I am on 2.6.12-rc3-mm2, and this issue
> is not fixed at all. Secondly, I'd like to say that I've pinpointed
> it a bit more. It appears only Empty partitions (type 0 in fdisk) do
> not create device nodes.
>
> Here is the partition table from fdisk, fdisk does run fine.. its just
> the fact this node is not created that threw me off before.
>
> Device Boot Start End Blocks Id System
> /dev/sdb1 * 1 2 16033+ 0 Empty
> /dev/sdb2 * 6 2431 19486845 b W95 FAT32
> /dev/sdb3 3 5 24097+ 83 Linux
>
>
> Notice, /dev/sdb1 is a Empty partition... in /dev I only have sdb,
> sdb2, and sdb3. No sdb1. Any help would be appreciated.
Looks like it might be a scsi issue. Redirecting to that mailing list
now. Anyone here have a clue?
thanks,
greg k-h
On Mon, 2 May 2005 20:14:21 -0700 Greg KH wrote:
| On Mon, May 02, 2005 at 10:51:24PM -0400, Joe wrote:
| > Ok, first off I'd like to say, I am on 2.6.12-rc3-mm2, and this issue
| > is not fixed at all. Secondly, I'd like to say that I've pinpointed
| > it a bit more. It appears only Empty partitions (type 0 in fdisk) do
| > not create device nodes.
| >
| > Here is the partition table from fdisk, fdisk does run fine.. its just
| > the fact this node is not created that threw me off before.
| >
| > Device Boot Start End Blocks Id System
| > /dev/sdb1 * 1 2 16033+ 0 Empty
| > /dev/sdb2 * 6 2431 19486845 b W95 FAT32
| > /dev/sdb3 3 5 24097+ 83 Linux
| >
| >
| > Notice, /dev/sdb1 is a Empty partition... in /dev I only have sdb,
| > sdb2, and sdb3. No sdb1. Any help would be appreciated.
|
| Looks like it might be a scsi issue. Redirecting to that mailing list
| now. Anyone here have a clue?
Could this 2.6.11.8 -stable patch fix it?
Subject: [04/07] partitions/msdos.c fix
Joe, can you test 2.6.11.8, please?
---
~Randy
On 5/2/05, Randy.Dunlap <[email protected]> wrote:
> Could this 2.6.11.8 -stable patch fix it?
> Subject: [04/07] partitions/msdos.c fix
>
> Joe, can you test 2.6.11.8, please?
>
> ---
> ~Randy
>
Randy, Can't run vanilla at the moment on this setup, any way you can
get the patch seperate? I also don't think that will fix it because
this is an empty, not a msdos partition.
Thanks,
Joe
On Tue, 3 May 2005 00:18:05 -0400 Joe wrote:
| On 5/2/05, Randy.Dunlap <[email protected]> wrote:
| > Could this 2.6.11.8 -stable patch fix it?
| > Subject: [04/07] partitions/msdos.c fix
| >
| > Joe, can you test 2.6.11.8, please?
| >
| > ---
| > ~Randy
| >
|
| Randy, Can't run vanilla at the moment on this setup, any way you can
| get the patch seperate? I also don't think that will fix it because
| this is an empty, not a msdos partition.
Yeah, I could be way off on this. Anyway, the patch is below.
---
~Randy
------------------
Erik reports this fixes an oops on boot for him.
From: Andries Brouwer <[email protected]>
A well-known kernel bug is that it guesses at the partition type and the
partitions on any disk it encounters. This is bad because needless I/O is
done, slowing down the boot, sometimes quite a lot, especially when I/O
errors occur. And it is bad because sometimes we guess wrong.
In other words, we need the user space command `partition', where
"partition -t dos /dev/sda" reads a DOS-type partition table. (And
"partition /dev/sda" tries all known heuristics to decide what type of
partitioning might be present.) The two variants are: (i) partition tells
the kernel to do the partition table reading, and (ii) partition uses partx
to read the partition table and tells the kernel one-by-one about the
partitions found this way.
Since this is a fundamental change, a long transition period is needed, and
that period could start with a kernel boot parameter telling the kernel not
to do partition table parsing on a particular disk, or a particular type of
disks, or all disks.
This could have been the intro to a patch doing that, but is not. (It is
just an RFC.)
The tiny patch below prompted the above - it was suggested by Uwe Bonnes
who encountered USB devices without partition table where our present
heuristics did not suffice to stop partition table parsing. It causes the
kernel to ignore partitions of type 0. A band-aid.
I think nobody uses such partitions seriously, but nevertheless this should
probably live in -mm for a while to see if anybody complains.
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
===== fs/partitions/msdos.c 1.26 vs 1.27 =====
--- 1.26/fs/partitions/msdos.c 2004-11-09 12:43:17 -08:00
+++ 1.27/fs/partitions/msdos.c 2005-03-07 20:41:42 -08:00
@@ -114,6 +114,9 @@ parse_extended(struct parsed_partitions
*/
for (i=0; i<4; i++, p++) {
u32 offs, size, next;
+
+ if (SYS_IND(p) == 0)
+ continue;
if (!NR_SECTS(p) || is_extended_partition(p))
continue;
@@ -430,6 +433,8 @@ int msdos_partition(struct parsed_partit
for (slot = 1 ; slot <= 4 ; slot++, p++) {
u32 start = START_SECT(p)*sector_size;
u32 size = NR_SECTS(p)*sector_size;
+ if (SYS_IND(p) == 0)
+ continue;
if (!size)
continue;
if (is_extended_partition(p)) {
-
Randy.Dunlap wrote:
> On Mon, 2 May 2005 20:14:21 -0700 Greg KH wrote:
>
> | On Mon, May 02, 2005 at 10:51:24PM -0400, Joe wrote:
> | > Ok, first off I'd like to say, I am on 2.6.12-rc3-mm2, and this issue
> | > is not fixed at all. Secondly, I'd like to say that I've pinpointed
> | > it a bit more. It appears only Empty partitions (type 0 in fdisk) do
> | > not create device nodes.
> | >
> | > Here is the partition table from fdisk, fdisk does run fine.. its just
> | > the fact this node is not created that threw me off before.
> | >
> | > Device Boot Start End Blocks Id System
> | > /dev/sdb1 * 1 2 16033+ 0 Empty
> | > /dev/sdb2 * 6 2431 19486845 b W95 FAT32
> | > /dev/sdb3 3 5 24097+ 83 Linux
> | >
> | >
> | > Notice, /dev/sdb1 is a Empty partition... in /dev I only have sdb,
> | > sdb2, and sdb3. No sdb1. Any help would be appreciated.
> |
> | Looks like it might be a scsi issue. Redirecting to that mailing list
> | now. Anyone here have a clue?
>
> Could this 2.6.11.8 -stable patch fix it?
> Subject: [04/07] partitions/msdos.c fix
>
> Joe, can you test 2.6.11.8, please?
It seems to me that this exactly the other way around. The patch is
probably already in -mm and is doing what it is supposed to do: don't
report partitions whose system ID == 0.
Can you try to give the empty partition a type different than zero? You
don't need to make a file system on it or anything, just change the type.
Or check if the patch Randy is pointing to is already in your tree and
revert it.
I think this is a good argument not to include this patch on the -stable
release...
--
Paulo Marques - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
On 5/3/05, Paulo Marques <[email protected]> wrote:
> Randy.Dunlap wrote:
> > Could this 2.6.11.8 -stable patch fix it?
> > Subject: [04/07] partitions/msdos.c fix
> >
> > Joe, can you test 2.6.11.8, please?
>
> It seems to me that this exactly the other way around. The patch is
> probably already in -mm and is doing what it is supposed to do: don't
> report partitions whose system ID == 0.
>
> Can you try to give the empty partition a type different than zero? You
> don't need to make a file system on it or anything, just change the type.
>
> Or check if the patch Randy is pointing to is already in your tree and
> revert it.
>
> I think this is a good argument not to include this patch on the -stable
> release...
>
> --
> Paulo Marques - http://www.grupopie.com
>
> All that is necessary for the triumph of evil is that good men do nothing.
> Edmund Burke (1729 - 1797)
>
You would be correct.. that patch is already in MM.. so this issue
continues, more input necessary.
Joe
Joe <[email protected]> wrote:
> Here is the partition table from fdisk, fdisk does run fine.. its just
> the fact this node is not created that threw me off before.
>
> Device Boot Start End Blocks Id System
> /dev/sdb1 * 1 2 16033+ 0 Empty
> /dev/sdb2 * 6 2431 19486845 b W95 FAT32
> /dev/sdb3 3 5 24097+ 83 Linux
>
> Notice, /dev/sdb1 is a Empty partition... in /dev I only have sdb,
> sdb2, and sdb3. No sdb1. Any help would be appreciated.
Some vendors depend on empty partitions not showing up. That's why this
patch was introduced.
BTW: Is there a special reason you why choose "empty"?
Is this partition showing up in other systems at all?
--
Top 100 things you don't want the sysadmin to say:
45. Was that YOUR directory?
On 5/3/05, Bodo Eggert <[email protected]>
<[email protected]> wrote:
> Joe <[email protected]> wrote:
>
> > Here is the partition table from fdisk, fdisk does run fine.. its just
> > the fact this node is not created that threw me off before.
> >
> > Device Boot Start End Blocks Id System
> > /dev/sdb1 * 1 2 16033+ 0 Empty
> > /dev/sdb2 * 6 2431 19486845 b W95 FAT32
> > /dev/sdb3 3 5 24097+ 83 Linux
> >
> > Notice, /dev/sdb1 is a Empty partition... in /dev I only have sdb,
> > sdb2, and sdb3. No sdb1. Any help would be appreciated.
>
> Some vendors depend on empty partitions not showing up. That's why this
> patch was introduced.
It would be interesting to see just how important it is to hide this.
> BTW: Is there a special reason you why choose "empty"?
> Is this partition showing up in other systems at all?
Actually, yes there is.. its a firmware partition that would normally
not be mounted, but in order to dd new firmware versions to it, I
depended on the node... which has ceased to exist.
I would like to see an easier workaround then just ignoring it like
that, but if its really needed....
Anyways, thanks everyone for the info, its much appreciated.
Joe
On Tue, 3 May 2005 23:49:55 -0400, Joe <[email protected]> wrote:
>
>Actually, yes there is.. its a firmware partition that would normally
>not be mounted, but in order to dd new firmware versions to it, I
>depended on the node... which has ceased to exist.
If it is firmware, looks unallocated to other systems, bad things
might happen if device plugged into windows box? (Assuming USB)
You still have 255 numbers to choose from for partition type? :)
--Grant.
On Tue, 3 May 2005, Joe wrote:
> On 5/3/05, Bodo Eggert <[email protected]>
> <[email protected]> wrote:
> > Joe <[email protected]> wrote:
> >
> > > Here is the partition table from fdisk, fdisk does run fine.. its just
> > > the fact this node is not created that threw me off before.
> > >
> > > Device Boot Start End Blocks Id System
> > > /dev/sdb1 * 1 2 16033+ 0 Empty
> > > /dev/sdb2 * 6 2431 19486845 b W95 FAT32
> > > /dev/sdb3 3 5 24097+ 83 Linux
> > >
> > > Notice, /dev/sdb1 is a Empty partition... in /dev I only have sdb,
> > > sdb2, and sdb3. No sdb1. Any help would be appreciated.
> >
> > Some vendors depend on empty partitions not showing up. That's why this
> > patch was introduced.
>
> It would be interesting to see just how important it is to hide this.
The size and position values were quite random, and the useless extra
partition caused some problems.
> > BTW: Is there a special reason you why choose "empty"?
> > Is this partition showing up in other systems at all?
>
> Actually, yes there is.. its a firmware partition that would normally
> not be mounted, but in order to dd new firmware versions to it, I
> depended on the node... which has ceased to exist.
So it isn't empty.-) I asume it will be in a custom system, so you can
hijack the compaq partition type (which was used for a similar purpose).
BTW: If you can do that, you should move the partition to the end of the
disk into the slower area of he disk.
--
"Bravery is being the only one who knows you're afraid."
-David Hackworth
On Mon, May 02, 2005 at 10:51:24PM -0400, Joe wrote:
> Ok, first off I'd like to say, I am on 2.6.12-rc3-mm2, and this issue
> is not fixed at all. Secondly, I'd like to say that I've pinpointed
> it a bit more. It appears only Empty partitions (type 0 in fdisk) do
> not create device nodes.
>
> Here is the partition table from fdisk, fdisk does run fine.. its just
> the fact this node is not created that threw me off before.
>
> Device Boot Start End Blocks Id System
> /dev/sdb1 * 1 2 16033+ 0 Empty
> /dev/sdb2 * 6 2431 19486845 b W95 FAT32
> /dev/sdb3 3 5 24097+ 83 Linux
>
>
> Notice, /dev/sdb1 is a Empty partition... in /dev I only have sdb,
> sdb2, and sdb3. No sdb1. Any help would be appreciated.
>
> Thanks,
> Joe
Today partition slots with partition type 0 are ignored.
I think you are the 4th I've seen to notice the change.
On Mon, May 02, 2005 at 08:14:21PM -0700, Greg KH wrote:
> On Mon, May 02, 2005 at 10:51:24PM -0400, Joe wrote:
> > Ok, first off I'd like to say, I am on 2.6.12-rc3-mm2, and this issue
> > is not fixed at all. Secondly, I'd like to say that I've pinpointed
> > it a bit more. It appears only Empty partitions (type 0 in fdisk) do
> > not create device nodes.
> >
> > Here is the partition table from fdisk, fdisk does run fine.. its just
> > the fact this node is not created that threw me off before.
> >
> > Device Boot Start End Blocks Id System
> > /dev/sdb1 * 1 2 16033+ 0 Empty
> > /dev/sdb2 * 6 2431 19486845 b W95 FAT32
> > /dev/sdb3 3 5 24097+ 83 Linux
> >
> >
> > Notice, /dev/sdb1 is a Empty partition... in /dev I only have sdb,
> > sdb2, and sdb3. No sdb1. Any help would be appreciated.
>
> Looks like it might be a scsi issue. Redirecting to that mailing list
> now. Anyone here have a clue?
Hmm - you even put this in 2.6.11.8, if I understand correctly.
Was that by mistake?
On Mon, May 02, 2005 at 08:26:20PM -0700, Randy.Dunlap wrote:
> On Mon, 2 May 2005 20:14:21 -0700 Greg KH wrote:
>
> | On Mon, May 02, 2005 at 10:51:24PM -0400, Joe wrote:
> | > Ok, first off I'd like to say, I am on 2.6.12-rc3-mm2, and this issue
> | > is not fixed at all. Secondly, I'd like to say that I've pinpointed
> | > it a bit more. It appears only Empty partitions (type 0 in fdisk) do
> | > not create device nodes.
> | >
> | > Here is the partition table from fdisk, fdisk does run fine.. its just
> | > the fact this node is not created that threw me off before.
> | >
> | > Device Boot Start End Blocks Id System
> | > /dev/sdb1 * 1 2 16033+ 0 Empty
> | > /dev/sdb2 * 6 2431 19486845 b W95 FAT32
> | > /dev/sdb3 3 5 24097+ 83 Linux
> | >
> | >
> | > Notice, /dev/sdb1 is a Empty partition... in /dev I only have sdb,
> | > sdb2, and sdb3. No sdb1. Any help would be appreciated.
> |
> | Looks like it might be a scsi issue. Redirecting to that mailing list
> | now. Anyone here have a clue?
>
> Could this 2.6.11.8 -stable patch fix it?
> Subject: [04/07] partitions/msdos.c fix
>
> Joe, can you test 2.6.11.8, please?
No, there is no problem but an intentional change in behaviour in -mm
and now also in 2.6.11.8.
Andries
On Tue, May 03, 2005 at 12:18:05AM -0400, Joe wrote:
> On 5/2/05, Randy.Dunlap <[email protected]> wrote:
> > Could this 2.6.11.8 -stable patch fix it?
> > Subject: [04/07] partitions/msdos.c fix
> >
> > Joe, can you test 2.6.11.8, please?
> >
> > ---
> > ~Randy
> >
>
> Randy, Can't run vanilla at the moment on this setup, any way you can
> get the patch seperate? I also don't think that will fix it because
> this is an empty, not a msdos partition.
>
> Thanks,
> Joe
There is a misunderstanding in terminology here.
"DOS-type partition table" is for most Linux users the only type
they have ever seen. The msdos in this context does not refer
to a particular filesystem, like the fat or msdos filesystem.
In case you have a problem because you want to access this partition,
give it some nonzero type.
Andries
* Andries Brouwer ([email protected]) wrote:
> No, there is no problem but an intentional change in behaviour in -mm
> and now also in 2.6.11.8.
I think this should be backed out of -stable.
On Fri, May 06, 2005 at 01:10:09AM -0700, Chris Wright wrote:
> * Andries Brouwer ([email protected]) wrote:
> > No, there is no problem but an intentional change in behaviour in -mm
> > and now also in 2.6.11.8.
>
> I think this should be backed out of -stable.
I was surprised to find it in, after I had written
============
Date: Sat, 30 Apr 2005 21:58:07 +0200
For the time being, although I do not object to the patch,
obviously, since it is my own, I cannot see any reason to
add it to the "fixed" release.
============
but maybe including it was done by mistake?
It wasn't mentioned, I think, in the changelog.
There was a report that it fixed an oops,
but the report is unconfirmed and ununderstood.
Should it be backed out of 2.6.11.8? Possibly - but if it will be
part of 2.6.12 or 2.6.13 then I would be inclined to leave it.
Andrew asks whether it should be removed from -mm.
Will first read all my mail and then reply to that letter.
Maybe you should coordinate with Andrew and take the same decision.
Andries
Andries Brouwer <[email protected]> wrote:
>
> On Fri, May 06, 2005 at 01:10:09AM -0700, Chris Wright wrote:
> > * Andries Brouwer ([email protected]) wrote:
> > > No, there is no problem but an intentional change in behaviour in -mm
> > > and now also in 2.6.11.8.
> >
> > I think this should be backed out of -stable.
>
> I was surprised to find it in, after I had written
>
> ============
> Date: Sat, 30 Apr 2005 21:58:07 +0200
>
> For the time being, although I do not object to the patch,
> obviously, since it is my own, I cannot see any reason to
> add it to the "fixed" release.
> ============
>
> but maybe including it was done by mistake?
> It wasn't mentioned, I think, in the changelog.
>
> There was a report that it fixed an oops,
> but the report is unconfirmed and ununderstood.
>
> Should it be backed out of 2.6.11.8? Possibly - but if it will be
> part of 2.6.12 or 2.6.13 then I would be inclined to leave it.
>
> Andrew asks whether it should be removed from -mm.
It was merged into Linus's tree on March 8th (via bk, thank gawd. How do
you find out that sort of info using git? Generating a full log is
cheating).
> Will first read all my mail and then reply to that letter.
> Maybe you should coordinate with Andrew and take the same decision.
I'm proposing that we revert that change from Linus's tree.
On Fri, 2005-05-06 at 02:05 -0700, Andrew Morton wrote:
> > Should it be backed out of 2.6.11.8? Possibly - but if it will be
> > part of 2.6.12 or 2.6.13 then I would be inclined to leave it.
> >
> > Andrew asks whether it should be removed from -mm.
>
> It was merged into Linus's tree on March 8th (via bk, thank gawd. How do
> you find out that sort of info using git? Generating a full log is
> cheating).
Well, moving offtopic, but it is of relevance to people who use git.
The answer is that the information exists (we can use the commit tree to
reconstruct the file data) but that no-one has yet come up with a file
history viewing tool. I think David Woodhouse is the closest to
producing one of these, David?
James
On Fri, 2005-05-06 at 02:05 -0700, Andrew Morton wrote:
> Andries Brouwer <[email protected]> wrote:
> >
> > On Fri, May 06, 2005 at 01:10:09AM -0700, Chris Wright wrote:
> > > * Andries Brouwer ([email protected]) wrote:
> > > > No, there is no problem but an intentional change in behaviour in -mm
> > > > and now also in 2.6.11.8.
> > >
> > > I think this should be backed out of -stable.
> >
> > I was surprised to find it in, after I had written
> >
> > ============
> > Date: Sat, 30 Apr 2005 21:58:07 +0200
> >
> > For the time being, although I do not object to the patch,
> > obviously, since it is my own, I cannot see any reason to
> > add it to the "fixed" release.
> > ============
> >
> > but maybe including it was done by mistake?
> > It wasn't mentioned, I think, in the changelog.
> >
> > There was a report that it fixed an oops,
> > but the report is unconfirmed and ununderstood.
> >
> > Should it be backed out of 2.6.11.8? Possibly - but if it will be
> > part of 2.6.12 or 2.6.13 then I would be inclined to leave it.
> >
> > Andrew asks whether it should be removed from -mm.
>
> It was merged into Linus's tree on March 8th (via bk, thank gawd. How do
> you find out that sort of info using git? Generating a full log is
> cheating).
You can get the commit-history for a file out of the web interface.
Here's another example, cause this change is not in the repository:
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=lib/kobject.c
Thanks,
Kay
On Fri, 2005-05-06 at 09:12 -0500, James Bottomley wrote:
> Well, moving offtopic, but it is of relevance to people who use git.
> The answer is that the information exists (we can use the commit tree
> to reconstruct the file data) but that no-one has yet come up with a
> file history viewing tool. I think David Woodhouse is the closest to
> producing one of these, David?
I posted a script which produces output along the lines of rev-tree's,
but which lists only commits relevant to a given file. However it lacked
correct information about the _branchpoint_ when branches were taken.
You could track the merges but not the full graph.
To do it properly would involve a modified version of rev-tree which
marks the 'interesting' commits and then prunes the uninteresting parts
before dumping what's left. I haven't got as far as _implementing_ that
yet.
--
dwmw2
On Fri, 2005-05-06 at 09:12 -0500, James Bottomley wrote:
> On Fri, 2005-05-06 at 02:05 -0700, Andrew Morton wrote:
> > > Should it be backed out of 2.6.11.8? Possibly - but if it will be
> > > part of 2.6.12 or 2.6.13 then I would be inclined to leave it.
> > >
> > > Andrew asks whether it should be removed from -mm.
> >
> > It was merged into Linus's tree on March 8th (via bk, thank gawd. How do
> > you find out that sort of info using git? Generating a full log is
> > cheating).
>
> Well, moving offtopic, but it is of relevance to people who use git.
> The answer is that the information exists (we can use the commit tree to
> reconstruct the file data) but that no-one has yet come up with a file
> history viewing tool. I think David Woodhouse is the closest to
> producing one of these, David?
Here (replace f=<file>):
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=lib/kobject.c
Or use Chris Mason's perl script:
http://marc.theaimsgroup.com/?l=git&m=111468881317040&w=2
I've attached it, updated to the recent git-* rename.
Thanks,
Kay
On Fri, May 06, 2005 at 01:10:09AM -0700, Chris Wright wrote:
> * Andries Brouwer ([email protected]) wrote:
> > No, there is no problem but an intentional change in behaviour in -mm
> > and now also in 2.6.11.8.
>
> I think this should be backed out of -stable.
I agree, I'll go do it in the tree right now, sorry about this.
greg k-h
>There is a misunderstanding in terminology here.
>"DOS-type partition table" is for most Linux users the only type
>they have ever seen. The msdos in this context does not refer
>to a particular filesystem, like the fat or msdos filesystem.
As long as we're talking terminology: fat and msdos aren't particular
filesystems. They're particular filesystem types. The contents of a
particular DOS-fomatted floppy disk would be an example of a particular
filesystem.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems