[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070618.230357.08341020.davem@davemloft.net>
Date: Mon, 18 Jun 2007 23:03:57 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: hch@....de
Cc: alan@...rguk.ukuu.org.uk, axboe@...nel.dk,
James.Bottomley@...elEye.com, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org,
paulus@...ba.org, Geert.Uytterhoeven@...ycom.com,
dwmw2@...radead.org
Subject: Re: [patch 4/6] ps3: Disk Storage Driver
From: Christoph Hellwig <hch@....de>
Date: Tue, 19 Jun 2007 07:53:58 +0200
> On Fri, Jun 15, 2007 at 02:19:17PM -0700, David Miller wrote:
> > Another quirk I have to deal with is that under LDOMs you
> > can export full disks and also just slices. So I'll have
> > to get down into the partition machinery to support that
> > somehow.
>
> What's the problem with that? Partition machinery is perfectly
> fine with just getting a raw disk without a partition table,
> and it obviously doesn't care if the raw disk it sees is part
> of a partition on the storage server.
Applications care :-)
One way of managing the partition table is by asking the storage
server for it. It supports giving back something that looks
like the Sun partition table layout, and also something that's
EFI based.
But the client can ignore that and read/write the partition
table itself.
What I really care about is what will work transparently for existing
userspace. In particular, distribution installers and existing tools
like fdisk.
When a slice it being exported, it's not being exported like that so
that the client can just spam a disk label into it, it's for exporting
one slice. So we might want (using the scsi naming as an arbitrary
example case) /dev/sda1 to be created but not /dev/sda
How exactly do you envision this kind of thing working?
Supporting the disk-server-provided partition table management
means providing ioctls() or whatever interface to get/set
the table. I had one idea to intercept reads/writes to the
first block(s) and translating those into partition management
commands to the disk server, but that is just too ugly to live. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists