All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andries E. Brouwer" <Andries.Brouwer@cwi.nl>
To: Karel Zak <kzak@redhat.com>
Cc: Andries Brouwer <Andries.Brouwer@cwi.nl>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/2] partitions: use sector size for EFI GPT
Date: Mon, 9 Nov 2009 20:58:32 +0100	[thread overview]
Message-ID: <20091109195832.GA25240@ub> (raw)
In-Reply-To: <20091109130827.GO5610@nb.net.home>

On Mon, Nov 09, 2009 at 02:08:27PM +0100, Karel Zak wrote:
> On Fri, Oct 23, 2009 at 12:36:15PM +0200, Karel Zak wrote:
> > Currently, kernel uses strictly 512-byte sectors for EFI GPT parsing.
> > That's wrong.
> 
>  Ping? Does anyone care about new disks with non-512byte sectors? 
>  (or fs/partitions is unmaintained area? ;-)

[as you must have noticed, I hardly do any kernel work any more;
probably there aren't many who know more about the ugly details
of DOS-type partition tables, but on the other hand nobody needs
such knowledge either]

>  The current kernel EFI GPT code in not compatible with the latest 
>  userspace and GPT partitions on disks with >512byte sectors will be 
>  *invisible* for Linux kernel.

Yes, I see that the current UEFI standard requires the use of the
disks block size. Roughly speaking I agree with your patch.

(Just read some current kernel code. The old hardsect_size stuff was
renamed to logical_block_size - funny, originally that was precisely
what hardsect was not.)

static size_t
read_lba(struct block_device *bdev, u64 lba, u8 * buffer, size_t count)
{
        size_t totalreadcount = 0;
	sector_t n = lba * (bdev_logical_block_size(bdev) / 512);

        if (!bdev || !buffer || lba > last_lba(bdev))
                return 0;

        while (count) {
                int copied = 512;
                Sector sect;
                unsigned char *data = read_dev_sector(bdev, n++, &sect);
                if (!data)
                        break;
                if (copied > count)
                        copied = count;
                memcpy(buffer, data, copied);
                put_dev_sector(sect);
                buffer += copied;
                totalreadcount +=copied;
                count -= copied;
        }
        return totalreadcount;
}

Ugly - it looks as if you call read_dev_sector 8 times and each time
do a put_dev_sector afterwards to forget it again. Doesnt that mean
that in order to read a 4096-byte sector the kernel goes to the hardware
8 times?

Andries


  parent reply	other threads:[~2009-11-09 20:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-23 10:36 [PATCH 1/2] partitions: use sector size for EFI GPT Karel Zak
2009-10-23 10:36 ` [PATCH 2/2] partitions: read whole sector with EFI GPT header Karel Zak
2009-11-09 13:08 ` [PATCH 1/2] partitions: use sector size for EFI GPT Karel Zak
2009-11-09 19:50   ` Jens Axboe
2009-11-09 19:58   ` Andries E. Brouwer [this message]
2009-11-09 21:33     ` Karel Zak
  -- strict thread matches above, loose matches on Subject: below --
2009-11-09 21:36 Karel Zak
2009-11-24  8:26 ` Jens Axboe

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=20091109195832.GA25240@ub \
    --to=andries.brouwer@cwi.nl \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=kzak@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.