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

On Fri, Jan 31, 2014 at 06:07:54AM -0700, Matthew Wilcox wrote:
> > 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.

Yes.  Or the caller is looking a single zone which has at least 256
sectors, the structure might be allocated on the stack:

{
	struct zone_status zs;

	zones = kmalloc(bdev, 0, 256, zs, 1);
	if (zones == 0)
		return -ENOSPC;
	....
}
	 
> 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.

Yes.  Zones which are off-line, full, or empty don't require storage
of the write pointer or checkpoint LBA, for example.  So if the vast
majority of the zones are either full, or empty, it wouldn't take that
much space to store the zone information.  One of the reasons why I
think we should have a interface using a function is so we can change
the underyling compressed representation without changing all of the
users of the zone status information.

Cheers,

					- Ted

  reply	other threads:[~2014-01-31 15:44 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
2014-01-31 15:44   ` Theodore Ts'o [this message]
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=20140131154433.GB18099@thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=matthew@wil.cx \
    /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.