search for: nr_sectors

...quot; #include "vddk-structs.h" @@ -67,6 +69,8 @@ static VixError (*VixDiskLib_GetInfo) (VixDiskLibHandle handle, VixDiskLibInfo * static void (*VixDiskLib_FreeInfo) (VixDiskLibInfo *info); static VixError (*VixDiskLib_Read) (VixDiskLibHandle handle, uint64_t start_sector, uint64_t nr_sectors, unsigned char *buf); static VixError (*VixDiskLib_Write) (VixDiskLibHandle handle, uint64_t start_sector, uint64_t nr_sectors, const unsigned char *buf); +static VixError (*VixDiskLib_QueryAllocatedBlocks) (VixDiskLibHandle diskHandle, uint64_t start_sector, uint64_t nr_sectors, uint64_t chunk_si...

This implements support for MBR logical partitions in nbdkit-partition-filter, complementing existing support in the partitioning plugin. Rich.

...) ((byte) == 0x5 || (byte) == 0xf || (byte) == 0x85) + struct mbr_partition { uint8_t part_type_byte; uint32_t start_sector; @@ -69,16 +75,16 @@ find_mbr_partition (struct nbdkit_next_ops *next_ops, void *nxdata, { int i; struct mbr_partition partition; + uint32_t ep_start_sector, ep_nr_sectors; + uint64_t ebr, next_ebr; + uint8_t sector[SECTOR_SIZE]; - if (partnum > 4) { - nbdkit_error ("MBR logical partitions are not supported"); - return -1; - } - + /* Primary partition. */ for (i = 0; i < 4; ++i) { get_mbr_partition (mbr, i, &partition); i...

...info) +{ + *info = calloc (1, sizeof (struct VixDiskLibInfo)); + (*info)->capacity = CAPACITY; + return VIX_OK; +} + +void +VixDiskLib_FreeInfo (VixDiskLibInfo *info) +{ + free (info); +} + +VixError +VixDiskLib_Read (VixDiskLibHandle handle, + uint64_t start_sector, uint64_t nr_sectors, + unsigned char *buf) +{ + size_t offset = start_sector * VIXDISKLIB_SECTOR_SIZE; + + memcpy (buf, disk + offset, nr_sectors * VIXDISKLIB_SECTOR_SIZE); + return VIX_OK; +} + +VixError +VixDiskLib_Write (VixDiskLibHandle handle, + uint64_t start_sector, uint64_t...

...itioning1.sh | 22 +++- > 3 files changed, 121 insertions(+), 11 deletions(-) > > @@ -69,16 +75,16 @@ find_mbr_partition (struct nbdkit_next_ops *next_ops, void *nxdata, > { > int i; > struct mbr_partition partition; > + uint32_t ep_start_sector, ep_nr_sectors; > + uint64_t ebr, next_ebr; > + uint8_t sector[SECTOR_SIZE]; > > - if (partnum > 4) { > - nbdkit_error ("MBR logical partitions are not supported"); > - return -1; > - } > - > + /* Primary partition. */ > for (i = 0; i < 4; ++i) { >...

...y have a single request outstanding at a time. */ + struct lguest_dma dma; + struct request *req; +}; + +/* Jens gave me this nice helper to end all chunks of a request. */ +static void end_entire_request(struct request *req, int uptodate) +{ + if (end_that_request_first(req, uptodate, req->hard_nr_sectors)) + BUG(); + add_disk_randomness(req->rq_disk); + blkdev_dequeue_request(req); + end_that_request_last(req, uptodate); +} + +static irqreturn_t lgb_irq(int irq, void *_bd) +{ + struct blockdev *bd = _bd; + unsigned long flags; + + if (!bd->req) { + pr_debug("No work!\n"); + retur...

...y have a single request outstanding at a time. */ + struct lguest_dma dma; + struct request *req; +}; + +/* Jens gave me this nice helper to end all chunks of a request. */ +static void end_entire_request(struct request *req, int uptodate) +{ + if (end_that_request_first(req, uptodate, req->hard_nr_sectors)) + BUG(); + add_disk_randomness(req->rq_disk); + blkdev_dequeue_request(req); + end_that_request_last(req, uptodate); +} + +static irqreturn_t lgb_irq(int irq, void *_bd) +{ + struct blockdev *bd = _bd; + unsigned long flags; + + if (!bd->req) { + pr_debug("No work!\n"); + retur...

Hey guys, Pasi mentioned on Li''s (and Owen''s) patches which provide TRIM/UNMAP support to the Linux backend/frontend that: " Isn''t the generic name for this functionality "discard" in Linux? and "trim" being the ATA specific discard-implementation, and "scsi unmap" the SAS/SCSI specific discard-implementation? Just

Dear list, This is the V4 of the trim support for xen-blkfront/blkback, Now we move BLKIF_OP_TRIM to BLKIF_OP_DISCARD, and dropped all "trim" stuffs in the patches, and use "discard" instead. Also we updated the helpers of blkif_x86_{32|64}_request or we will meet problems using a non-native protocol. And this patch has been tested with both SSD and raw file, with SSD we will

I think this addresses everything in Eric's v2 review. Note that the first patch is best viewed using ‘-w’ to ignore whitespaces changes. Rich.

This is a revised version of the two series previously posted here: https://www.redhat.com/archives/libguestfs/2019-January/msg00137.html https://www.redhat.com/archives/libguestfs/2019-January/msg00139.html There have been many smaller changes but the highlights are: - Using SECTOR_SIZE instead of hard-coding 512 everywhere. - Additional safety checks that the EBR chain doesn't jump

...&block_list); @@ -809,7 +827,7 @@ vddk_extents (void *handle, uint32_t count, uint64_t offset, uint32_t flags, "handle, %" PRIu64 " sectors, %" PRIu64 " sectors, " "%d sectors", start_sector, nr_sectors, VIXDISKLIB_MIN_CHUNK_SIZE); - err = VixDiskLib_QueryAllocatedBlocks (h->handle, + err = VixDiskLib_QueryAllocatedBlocks (single_link ? h->handle_single_link : h->handle, start_sector, nr_sectors,...

Hi Alasdair, This is dm-ioband v1.12.3 release that is a minor update to avoid sparse warnings other than related to the event tracing. (I used sparse-2009-07-29.) This patch can be applied to the current dm-devel tree and 2.6.31-rc4, so could you please replace dm-add-ioband.patch in your tree with this? And I would appreciate it if you would let me know your thoughts about merging dm-ioband to

Hi Alasdair, This is dm-ioband v1.12.3 release that is a minor update to avoid sparse warnings other than related to the event tracing. (I used sparse-2009-07-29.) This patch can be applied to the current dm-devel tree and 2.6.31-rc4, so could you please replace dm-add-ioband.patch in your tree with this? And I would appreciate it if you would let me know your thoughts about merging dm-ioband to

Hi Alasdair, This is dm-ioband v1.12.3 release that is a minor update to avoid sparse warnings other than related to the event tracing. (I used sparse-2009-07-29.) This patch can be applied to the current dm-devel tree and 2.6.31-rc4, so could you please replace dm-add-ioband.patch in your tree with this? And I would appreciate it if you would let me know your thoughts about merging dm-ioband to

Hi all, These are new releases of dm-ioband and blkio-cgroup. The major changes of these releases are: - dm-ioband can be configured through the cgroup interface. The bandwidth can be assigned on a per cgroup per block device basis. - The event tracing is supported that helps in debugging and monitoring dm-ioband. - A document for blkio-cgroup is available at

Hi all, These are new releases of dm-ioband and blkio-cgroup. The major changes of these releases are: - dm-ioband can be configured through the cgroup interface. The bandwidth can be assigned on a per cgroup per block device basis. - The event tracing is supported that helps in debugging and monitoring dm-ioband. - A document for blkio-cgroup is available at

Hi all, These are new releases of dm-ioband and blkio-cgroup. The major changes of these releases are: - dm-ioband can be configured through the cgroup interface. The bandwidth can be assigned on a per cgroup per block device basis. - The event tracing is supported that helps in debugging and monitoring dm-ioband. - A document for blkio-cgroup is available at

...) with a CF card mounted as EXT3. I'll copy some system details below... Anyway, I'm getting some drive errors and I'm wondering if they're due to bad/old drivers, something with EXT3 and CF latency, or something else entirely. These are the errors: hda: write_intr error1: nr_sectors=1, stat=0x51 hda: write_intr: status=0x51 { DriveReady SeekComplete Error } hda: write_intr: error=0x04 { DriveStatusError } end_request: I/O error, dev 03:01 (hda), sector 528431 Let me know if you have any idea what I could do to fix these issues. Ideally it wouldn't involve a recompil...

Hi Alasdair, This is dm-ioband v1.12.2 release that is a minor update to fit the current dm-devel tree. Could you please replace dm-add-ioband.patch in your tree with this patch? And I would appreciate it if you would let me know your thoughts about merging dm-ioband to upstream. Thanks, Ryo Tsuruta About dm-ioband: dm-ioband is an I/O bandwidth controller implemented as a device-mapper