<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/md/bitmap.h, branch v4.1</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v4.1</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v4.1'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2015-04-21T21:59:39Z</updated>
<entry>
<title>md-cluster: re-add capabilities</title>
<updated>2015-04-21T21:59:39Z</updated>
<author>
<name>Goldwyn Rodrigues</name>
<email>rgoldwyn@suse.de</email>
</author>
<published>2015-04-14T15:45:42Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=97f6cd39da227459cb46ed4088d37d5d8db51c50'/>
<id>urn:sha1:97f6cd39da227459cb46ed4088d37d5d8db51c50</id>
<content type='text'>
When "re-add" is writted to /sys/block/mdXX/md/dev-YYY/state,
the clustered md:

1. Sends RE_ADD message with the desc_nr. Nodes receiving the message
   clear the Faulty bit in their respective rdev-&gt;flags.
2. The node initiating re-add, gathers the bitmaps of all nodes
   and copies them into the local bitmap. It does not clear the bitmap
   from which it is copying.
3. Initiating node schedules a md recovery to sync the devices.

Signed-off-by: Guoqing Jiang &lt;gqjiang@suse.com&gt;
Signed-off-by: Goldwyn Rodrigues &lt;rgoldwyn@suse.com&gt;
Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
</content>
</entry>
<entry>
<title>Copy set bits from another slot</title>
<updated>2015-02-23T15:59:05Z</updated>
<author>
<name>Goldwyn Rodrigues</name>
<email>rgoldwyn@suse.com</email>
</author>
<published>2014-06-07T05:36:26Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=11dd35daaab86d12270d23a10e8d242846a8830a'/>
<id>urn:sha1:11dd35daaab86d12270d23a10e8d242846a8830a</id>
<content type='text'>
bitmap_copy_from_slot reads the bitmap from the slot mentioned.
It then copies the set bits to the node local bitmap.

This is helper function for the resync operation on node failure.

bitmap_set_memory_bits() currently assumes it is only run at startup and that
they bitmap is currently empty.  So if it finds that a region is already
marked as dirty, it won't mark it dirty again. Change bitmap_set_memory_bits()
to always set the NEEDED_MASK bit if 'needed' is set.

Signed-off-by: Goldwyn Rodrigues &lt;rgoldwyn@suse.com&gt;
</content>
</entry>
<entry>
<title>bitmap_create returns bitmap pointer</title>
<updated>2015-02-23T15:57:57Z</updated>
<author>
<name>Goldwyn Rodrigues</name>
<email>rgoldwyn@suse.com</email>
</author>
<published>2014-06-06T17:43:49Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f9209a323547f054c7439a3bf67c45e64a054bdd'/>
<id>urn:sha1:f9209a323547f054c7439a3bf67c45e64a054bdd</id>
<content type='text'>
This is done to have multiple bitmaps open at the same time.

Signed-off-by: Goldwyn Rodrigues &lt;rgoldwyn@suse.com&gt;
</content>
</entry>
<entry>
<title>Use separate bitmaps for each nodes in the cluster</title>
<updated>2015-02-23T13:30:11Z</updated>
<author>
<name>Goldwyn Rodrigues</name>
<email>rgoldwyn@suse.com</email>
</author>
<published>2014-06-06T16:50:56Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b97e92574c0bf335db1cd2ec491d8ff5cd5d0b49'/>
<id>urn:sha1:b97e92574c0bf335db1cd2ec491d8ff5cd5d0b49</id>
<content type='text'>
On-disk format:

0                    4k                     8k                    12k
-------------------------------------------------------------------
| idle                | md super            | bm super [0] + bits |
| bm bits[0, contd]   | bm super[1] + bits  | bm bits[1, contd]   |
| bm super[2] + bits  | bm bits [2, contd]  | bm super[3] + bits  |
| bm bits [3, contd]  |                     |                     |

Bitmap super has a field nodes, which defines the maximum number
of nodes the device can use. While reading the bitmap super, if
the cluster finds out that the number of nodes is &gt; 0:
1. Requests the md-cluster module.
2. Calls md_cluster_ops-&gt;join(), which sets up clustering such as
   joining DLM lockspace.

Since the first time, the first bitmap is read. After the call
to the cluster_setup, the bitmap offset is adjusted and the
superblock is re-read. This also ensures the bitmap is read
the bitmap lock (when bitmap lock is introduced in later patches)

Questions:
1. cluster name is repeated in all bitmap supers. Is that okay?

Signed-off-by: Goldwyn Rodrigues &lt;rgoldwyn@suse.com&gt;
</content>
</entry>
<entry>
<title>Add node recovery callbacks</title>
<updated>2015-02-23T13:30:11Z</updated>
<author>
<name>Goldwyn Rodrigues</name>
<email>rgoldwyn@suse.com</email>
</author>
<published>2014-03-30T05:42:49Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=cf921cc19cf7c1e99f730a2faa02d80817d684a2'/>
<id>urn:sha1:cf921cc19cf7c1e99f730a2faa02d80817d684a2</id>
<content type='text'>
DLM offers callbacks when a node fails and the lock remastery
is performed:

1. recover_prep: called when DLM discovers a node is down
2. recover_slot: called when DLM identifies the node and recovery
		can start
3. recover_done: called when all nodes have completed recover_slot

recover_slot() and recover_done() are also called when the node joins
initially in order to inform the node with its slot number. These slot
numbers start from one, so we deduct one to make it start with zero
which the cluster-md code uses.

Signed-off-by: Goldwyn Rodrigues &lt;rgoldwyn@suse.com&gt;
</content>
</entry>
<entry>
<title>Add number of nodes to bitmap structure for clustering</title>
<updated>2015-02-23T13:28:30Z</updated>
<author>
<name>Goldwyn Rodrigues</name>
<email>rgoldwyn@suse.com</email>
</author>
<published>2014-03-07T16:30:43Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=183bdf5106af069a774146c4f910a80ad1f57485'/>
<id>urn:sha1:183bdf5106af069a774146c4f910a80ad1f57485</id>
<content type='text'>
Signed-off-by: Goldwyn Rodrigues &lt;rgoldwyn@suse.com&gt;
</content>
</entry>
<entry>
<title>kernfs: s/sysfs_dirent/kernfs_node/ and rename its friends accordingly</title>
<updated>2013-12-11T23:28:36Z</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2013-12-11T19:11:53Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=324a56e16e44baecac3ca799fd216154145c14bf'/>
<id>urn:sha1:324a56e16e44baecac3ca799fd216154145c14bf</id>
<content type='text'>
kernfs has just been separated out from sysfs and we're already in
full conflict mode.  Nothing can make the situation any worse.  Let's
take the chance to name things properly.

This patch performs the following renames.

* s/sysfs_elem_dir/kernfs_elem_dir/
* s/sysfs_elem_symlink/kernfs_elem_symlink/
* s/sysfs_elem_attr/kernfs_elem_file/
* s/sysfs_dirent/kernfs_node/
* s/sd/kn/ in kernfs proper
* s/parent_sd/parent/
* s/target_sd/target/
* s/dir_sd/parent/
* s/to_sysfs_dirent()/rb_to_kn()/
* misc renames of local vars when they conflict with the above

Because md, mic and gpio dig into sysfs details, this patch ends up
modifying them.  All are sysfs_dirent renames and trivial.  While we
can avoid these by introducing a dummy wrapping struct sysfs_dirent
around kernfs_node, given the limited usage outside kernfs and sysfs
proper, I don't think such workaround is called for.

This patch is strictly rename only and doesn't introduce any
functional difference.

- mic / gpio renames were missing.  Spotted by kbuild test robot.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Neil Brown &lt;neilb@suse.de&gt;
Cc: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Cc: Ashutosh Dixit &lt;ashutosh.dixit@intel.com&gt;
Cc: kbuild test robot &lt;fengguang.wu@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>md/bitmap: record the space available for the bitmap in the superblock.</title>
<updated>2012-05-22T03:55:34Z</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2012-05-22T03:55:34Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1dff2b87a34a1ac1d1898ea109bf97ed396aca53'/>
<id>urn:sha1:1dff2b87a34a1ac1d1898ea109bf97ed396aca53</id>
<content type='text'>
Now that bitmaps can grow and shrink it is best if we record
how much space is available.  This means that when
we reduce the size of the bitmap we won't "lose" the space
for late when we might want to increase the size of the bitmap
again.

Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
</content>
</entry>
<entry>
<title>md/bitmap: add bitmap_resize function to allow bitmap resizing.</title>
<updated>2012-05-22T03:55:25Z</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2012-05-22T03:55:25Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d60b479d177a5735b6b4db6ee5280ef6653f50e7'/>
<id>urn:sha1:d60b479d177a5735b6b4db6ee5280ef6653f50e7</id>
<content type='text'>
This function will allocate the new data structures and copy
bits across from old to new, allowing for the possibility that the
chunksize has changed.

Use the same function for performing the initial allocation
of the structures.  This improves test coverage.

When bitmap_resize is used to resize an existing bitmap, it
only copies '1' bits in, not '0' bits.
So when allocating the bitmap, ensure everything is initialised
to ZERO.

Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
</content>
</entry>
<entry>
<title>md/bitmap: create a 'struct bitmap_counts' substructure of 'struct bitmap'</title>
<updated>2012-05-22T03:55:24Z</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2012-05-22T03:55:24Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=40cffcc0e8f9f6e295630cb8b8d58a13baa6c7f9'/>
<id>urn:sha1:40cffcc0e8f9f6e295630cb8b8d58a13baa6c7f9</id>
<content type='text'>
The new "struct bitmap_counts" contains all the fields that are
related to counting the number of active writes in each bitmap chunk.

Having this separate will make it easier to change the chunksize
or overall size of a bitmap atomically.

Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
</content>
</entry>
</feed>
