search for: insert_mapping

The current btrfs support did not handled multiple stripes stored in chunk items, hence skipping the physical addresses that were needed to do the mapping. Besides, the chunk tree may contain DEV_ITEM keys which store information on all of the underlying block devices, so we must skip them instead of finishing lookup. The bug was reproduced with btrfs-progs v4.2.2. Cc: Gene Cumm <gene.cumm

The current btrfs support did not handled multiple stripes stored in chunk items, hence skipping the physical addresses that were needed to do the mapping. Besides, the chunk tree may contain DEV_ITEM keys which store information on all of the underlying block devices, so we must skip them instead of finishing lookup. The bug was reproduced with btrfs-progs v4.2.2. Cc: Gene Cumm <gene.cumm

The current btrfs support did not handled multiple stripes stored in chunk items, hence skipping the physical addresses that were needed to do the mapping. Besides, the chunk tree may contain DEV_ITEM keys which store information on all of the underlying block devices, so we must skip them instead of finishing lookup. The bug was reproduced with btrfs-progs v4.2.2. Cc: Gene Cumm <gene.cumm

On Thu, Dec 24, 2015 at 8:58 AM, Paulo Alcantara <pcacjr at gmail.com> wrote: > The current btrfs support did not handled multiple stripes stored in > chunk items, hence skipping the physical addresses that were needed to > do the mapping. > > Besides, the chunk tree may contain DEV_ITEM keys which store > information on all of the underlying block devices, so we must skip

...format itself permits overlaps for shorthands for special-casing subregions. Is there a syntax for explicitly mentioning a subset is unmapped even after a larger mapping is applied first (perhaps useful for redacting a portion of a disk containing sensitive information)? > +static int > +insert_mapping (struct map *map, const struct mapping *new_mapping) > +{ > + size_t i; > + > + /* Adjust existing mappings if they overlap with this mapping. */ > + for (i = 0; i < map->nr_map; ++i) { > + if (mappings_overlap (&map->map[i], new_mapping)) { > + /* The f...

...ive information)? It's a good idea for a TODO item, so I'll add it there. At the moment it's possible to express this in the map file, but only by positively listing the regions you want to be mapped, not by negatively listing regions you want unmapped. > >+static int > >+insert_mapping (struct map *map, const struct mapping *new_mapping) > >+{ > >+ size_t i; > >+ > >+ /* Adjust existing mappings if they overlap with this mapping. */ > >+ for (i = 0; i < map->nr_map; ++i) { > >+ if (mappings_overlap (&map->map[i], new_mapping)...

...); +} + +/* Return the highest address in the map+1. */ +int64_t +map_size (struct map *map) +{ + if (map->nr_map == 0) + return 0; + else + return map->map[map->nr_map-1].rq_end + 1; +} + +/* Add a single new mapping at the end of the map. Does NOT maintain + * the invariant, use insert_mapping instead. + */ +static int +add_mapping (struct map *map, const struct mapping *mapping) +{ + struct mapping *new_map; + + map->nr_map++; + new_map = realloc (map->map, map->nr_map * sizeof map->map[0]); + if (new_map == NULL) { + nbdkit_error ("realloc: %m"); + retur...

This patch series proposes two new filters. * truncate: This can truncate, extend, round up or round down the size of a plugin/device. A typical usage is to fix the qemu problem that it can only handle devices which are a multiple of 512-bytes: nbdkit --filter=truncate random size=500 round-up=512 This will serve a virtual device with size 512 bytes. Reading from the last 12 bytes will