public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: 2.4.11 loses sda9
@ 2001-10-11  5:07 Alexander Viro
  2001-10-11  5:20 ` arvest
  2001-10-11 18:22 ` Guest section DW
  0 siblings, 2 replies; 20+ messages in thread
From: Alexander Viro @ 2001-10-11  5:07 UTC (permalink / raw)
  To: linux-kernel



>  I recompiled (I used the same .10 conf) and rebooted, but my reboot halted 
>because /dev/sda9 didnt exist.  I checked this in fdisk, and it didnt see it. 
> I rebooted to the 2.4.10 kernel, and sda9 was there.  What happened?

Information from fdisk would help - from both versions (with 2.4.11 you'll
need to boot with init=/bin/sh, obviously).  It may be a bug in partition
code, it may be something fishy with guessing geometry (SCSI uses bread()
for that) and it may be something fishy in block devices in pagecache stuff.

If you have sfdisk, sfdisk /dev/sda -O /tmp/foo + mailing the result would
make debugging the thing much simpler (that one - from the 2.4.10).



^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: 2.4.11 loses sda9
@ 2001-10-12  0:07 Andries.Brouwer
  0 siblings, 0 replies; 20+ messages in thread
From: Andries.Brouwer @ 2001-10-12  0:07 UTC (permalink / raw)
  To: Andries.Brouwer, viro; +Cc: adilger, arvest, linux-kernel

>> It is not difficult at all to get a kernel up and running that has
>> kdev_t a pointer type.

>  When do you free them?

That is not the purpose of the demo. It is just to convince
you that your fear (used as number) is almost entirely unfounded.

Andries

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: 2.4.11 loses sda9
@ 2001-10-11 22:11 Andries.Brouwer
  2001-10-11 22:26 ` Alexander Viro
  0 siblings, 1 reply; 20+ messages in thread
From: Andries.Brouwer @ 2001-10-11 22:11 UTC (permalink / raw)
  To: Andries.Brouwer, viro; +Cc: adilger, arvest, linux-kernel

> Right now we have a big and fairly nasty mix of the stuff that can be
> turned in pointer to block device, pointer to character device _and_
> stuff that is used as numbers.

Not really. I don't know whether you ever tried the experiment
and compiled kdev_t as a pointer to a struct with two members
namely major and minor, where the struct is allocated by MKDEV().
Very few places break, and these places are very easy to fix.
Stuff that is used as numbers can be forgotten quickly.
It is not difficult at all to get a kernel up and running that has
kdev_t a pointer type.

> Moreover, allocation policy for these structures is a tricky beast.

Yes. I entirely agree. All the rest is a mechanical action.
(Or, more precisely, removable modules require freeing, and
freeing requires refcounting. It is the refcounting that is
work, more than the allocation.)

Andries

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: 2.4.11 loses sda9
@ 2001-10-11 20:29 Andries.Brouwer
  2001-10-11 20:54 ` Alexander Viro
  0 siblings, 1 reply; 20+ messages in thread
From: Andries.Brouwer @ 2001-10-11 20:29 UTC (permalink / raw)
  To: Andries.Brouwer, viro; +Cc: adilger, arvest, linux-kernel

    From viro@math.psu.edu Thu Oct 11 21:19:27 2001

    On Thu, 11 Oct 2001 Andries.Brouwer@cwi.nl wrote:

    > so as to make it easy to switch between compiles where
    > a kdev_t is a number and we use the infamous arrays,
    > and compiles where a kdev_t is a pointer to a device struct,
    > and no arrays exist, I now see that get_hardsect_size(dev)
    > is replaced by
    >         get_hardsect_size(to_kdev_t(bdev->bd_dev))
    > . Yecch.
    > Al, I never understood why you want to introduce a
    > struct block_device * to do precisely what kdev_t
    > was designed to do.]
     
    We had been through that way too many times.  You know what problems
    with unified device struct I've brought before.  You know what
    problems I have with your 64bit dev_t.  And you know _very_ well that
    any patches in that area should be done in small steps.

    Hell, I'd prefer that one to be done _much_ slower - with decent
    debugging between the steps instead of "we've got to close the
    holes opened by bdev-in-pagecache _NOW_" kind of situation we'd got.

    IMO eventually we should have per-disk structure and keep reference to
    it from struct block_device.  Then get_hardsect_size() wiuld turn into
    access to field of that beast (and would take struct block_device *
    as an argument).  But that's 2.5 stuff and I bloody refuse to participate
    in attempts to do everything in one huge leap.  One we'd got is already
    bad enough.

You invent two strawmen to divert attention from the question:

> You know what problems I have with your 64bit dev_t.

Well, in fact I don't know, except that you announced to fork the
source once it got one. But that is an entirely separate discussion
and has nothing to do with kdev_t.  A dev_t is what goes into the kernel
at the mknod system call, and comes out of the kernel at the stat
system call, and roughly speaking has no other significance.
It plays a role in NFS, but NFS already uses a 64bit dev_t.

Kernel patches for a 64bit dev_t are entirely orthogonal to kdev_t work.

> I refuse to participate in attempts to do everything in one huge leap.

Well, it is not me who invents the idea of big changes at once.
It was mostly Linus who did not like intermediate code.

I think I can go to my goal in many small steps avoiding intermediate code,
although life is a bit easier with intermediate stuff like get_hardsect_size(dev).

But the size of the leaps towards the goal has very little to do
with the design of the goal.

So those are your two strawmen. Yes, there is one more sentence:

> You know what problems with unified device struct I've brought before.

I don't mind splitting kdev_t into kbdev_t and kcdev_t.
Keeping the former requires a cast or a union somewhere.
Splitting requires some code duplication.
Altogether there is very little difference between the two setups.

Remains the question, let me repeat:
"Al, I never understood why you want to introduce a struct block_device *
 to do precisely what kdev_t was designed to do."

I see that you are making small steps away from my goal, so I hope
you know very precisely where you want to go and how to get there.

> But that's 2.5 stuff

Yes, precisely. But you do not wait for 2.5 but start walking already.

Andries

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: 2.4.11 loses sda9
@ 2001-10-11 19:07 Andries.Brouwer
  2001-10-11 19:19 ` Alexander Viro
  0 siblings, 1 reply; 20+ messages in thread
From: Andries.Brouwer @ 2001-10-11 19:07 UTC (permalink / raw)
  To: adilger, arvest; +Cc: linux-kernel, viro

On Thu, Oct 11, 2001 at 12:08:14AM -0600, Andreas Dilger wrote:

> You probably need to go into fdisk and change the partition type of
> sda9 from "0" to "83" (or any other non-zero type).  There is a
> reason that it is saying "omitting empty partition (9)" at boot,
> and "fdisk -l" doesn't list it - because type "0" means "I don't exist".

If I am not mistaken, it is fdisk rather than the kernel that says
"omitting empty partition (9)". (And the latest fdisk no longer
deletes partitions of type 0 from its listings.)
The sys_type field never had any significance to the kernel.

Andries


[By the way, it is a sad sight to see patch-2.4.11.
Where my own sources use  dev->hardsect_size , and
intermediate sources use  get_hardsect_size(dev)
an inline function defined roughly either as
        dev->hardsect_size
or as
        hardsect_size[MAJOR(dev)][MINOR(dev)]
so as to make it easy to switch between compiles where
a kdev_t is a number and we use the infamous arrays,
and compiles where a kdev_t is a pointer to a device struct,
and no arrays exist, I now see that get_hardsect_size(dev)
is replaced by
        get_hardsect_size(to_kdev_t(bdev->bd_dev))
. Yecch.
Al, I never understood why you want to introduce a
struct block_device * to do precisely what kdev_t
was designed to do.]

^ permalink raw reply	[flat|nested] 20+ messages in thread
* 2.4.11 loses sda9
@ 2001-10-11  4:22 arvest
  0 siblings, 0 replies; 20+ messages in thread
From: arvest @ 2001-10-11  4:22 UTC (permalink / raw)
  To: linux-kernel


  I recompiled (I used the same .10 conf) and rebooted, but my reboot halted 
because /dev/sda9 didnt exist.  I checked this in fdisk, and it didnt see it. 
 I rebooted to the 2.4.10 kernel, and sda9 was there.  What happened?

^ permalink raw reply	[flat|nested] 20+ messages in thread
end of thread, other threads:[~2001-10-12  0:08 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-10-11  5:07 2.4.11 loses sda9 Alexander Viro
2001-10-11  5:20 ` arvest
2001-10-11  5:23   ` Alexander Viro
2001-10-11  5:45     ` arvest
2001-10-11  6:08       ` Andreas Dilger
2001-10-11  6:17         ` Alexander Viro
2001-10-11 16:41         ` arvest
2001-10-11 16:46           ` Ignacio Vazquez-Abrams
2001-10-11 16:50             ` Alexander Viro
2001-10-11 17:23               ` Alexander Viro
2001-10-11 18:22 ` Guest section DW
2001-10-11 18:25   ` Alexander Viro
  -- strict thread matches above, loose matches on Subject: below --
2001-10-12  0:07 Andries.Brouwer
2001-10-11 22:11 Andries.Brouwer
2001-10-11 22:26 ` Alexander Viro
2001-10-11 20:29 Andries.Brouwer
2001-10-11 20:54 ` Alexander Viro
2001-10-11 19:07 Andries.Brouwer
2001-10-11 19:19 ` Alexander Viro
2001-10-11  4:22 arvest

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox