All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [RFC] Draft Linux kernel interfaces for ZBC drives
Date: Fri, 31 Jan 2014 06:07:54 -0700	[thread overview]
Message-ID: <20140131130754.GI20939@parisc-linux.org> (raw)
In-Reply-To: <nsxtxckhfsh.fsf@closure.thunk.org>

On Fri, Jan 31, 2014 at 12:38:22AM -0500, Theodore Ts'o wrote:
> /*
>  * Note: this structure is 24 bytes.  Using 256 MB zones, an 8TB drive
>  * will have 32,768 zones.   That means if we tried to use a contiguous
>  * array we would need to allocate 768k of contiguous, non-swappable
>  * kernel memory.  (Boo, hiss.) 
>  *
>  * This large enough that it would be painful to hang an array off the
>  * block_device structure.  So we will define a function
>  * blkdev_query_zones() to selectively return information for some
>  * number of zones.
>  */
> struct zone_status {
>        sector_t	z_start;
>        __u32	z_length;
>        __u32	z_write_ptr_offset;  /* offset */
>        __u32	z_checkpoint_offset; /* offset */
>        __u32	z_flags;	     /* full, ro, offline, reset_requested */
> };
> 
> /*
>  * Query the block_device bdev for information about the zones
>  * starting at start_sector that match the criteria specified by
>  * free_sectors_criteria.  Zone status information for at most
>  * max_zones will be placed into the memory array ret_zones.  The
>  * return value contains the number of zones actually returned.
>  *
>  * If free_sectors_criteria is positive, then return zones that have
>  * at least that many sectors available to be written.  If it is zero,
>  * then match all zones.  If free_sectors_criteria is negative, then
>  * return the zones that match the following criteria:
>  *
>  *      -1     Return all read-only zones
>  *      -2     Return all offline zones
>  *      -3     Return all zones where the write ptr != the checkpoint ptr
>  */
> extern int blkdev_query_zones(struct block_device *bdev,
> 			      sector_t start_sector,
> 			      int free_sectors_criteria,
>        			      struct zone_status *ret_zones,
> 			      int max_zones);

So the caller does:

	zones = kmalloc(max * sizeof *zones, GFP_KERNEL);
	blkdev_query_zones(bdev, sector, fsc, zones, max);
...
	kfree(zones);

Just want to be sure I understand the lifetime rules on the memory used.
I imagine the block layer will have some kind of compressed representation,
probably a tree of some kind, then expand that representation into the
zone_status.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

  reply	other threads:[~2014-01-31 13:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-31  5:38 [RFC] Draft Linux kernel interfaces for ZBC drives Theodore Ts'o
2014-01-31 13:07 ` Matthew Wilcox [this message]
2014-01-31 15:44   ` Theodore Ts'o
2014-02-03 21:01 ` Jeff Moyer
2014-02-03 21:07   ` Martin K. Petersen
2014-02-03 21:38   ` Theodore Ts'o
2014-02-03 22:26     ` Jeff Moyer
2014-02-03 21:03 ` Eric Sandeen
2014-02-03 22:17   ` Theodore Ts'o
2014-02-04  2:00 ` HanBin Yoon
2014-02-04 16:27   ` Theodore Ts'o
2014-02-11 18:43 ` [RFC] Draft Linux kernel interfaces for SMR/ZBC drives Theodore Ts'o
2014-02-11 19:04   ` Andreas Dilger
2014-02-11 19:53     ` Theodore Ts'o
2014-02-13  2:08       ` Andreas Dilger
2014-02-13  3:09         ` Theodore Ts'o
2014-02-21 10:02 ` [RFC] Draft Linux kernel interfaces for ZBC drives Rohan Puri
2014-02-21 15:49   ` Theodore Ts'o
2014-02-25  9:36     ` Rohan Puri

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=20140131130754.GI20939@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.