Re: [Cluster-devel] [ClusterLabs Developers] Pacemaker 2.1.0: Should we rename the master branch?
On 10/20/2020 7:26 PM, Andrew Price wrote:
[CC+ cluster-devel]
On 19/10/2020 23:59, Ken Gaillot wrote:
On Mon, 2020-10-19 at 07:19 +0200, Fabio M. Di Nitto wrote:
Hi Ken,
On 10/2/2020 8:02 PM, Digimer wrote:
On 2020-10-02 1:12 p.m., Ken Gaillot wrote:
Hi all,
I sent a message to the us...@clusterlabs.org list about
releasing
Pacemaker 2.1.0 next year.
Coincidentally, there is a plan in the git and Github communities
to
change the default git branch from "master" to "main":
https://github.com/github/renaming
The rationale for the change is not the specific meaning as used
in
branching, but rather to avoid any possibility of fostering an
exclusionary environment, and to replace generic metaphors with
something more obvious (especially to non-native English
speakers).
No objections to the change, but please let´s coordinate the change
across all HA projects at once, or CI is going to break badly as the
concept of master branch is embedded everywhere and not per-project.
Presumably this would be all the projects built by jenkins?
correct.
booth
corosync
fence-agents
fence-virt
knet
libqb
pacemaker
pcs
qdevice
resource-agents
sbd
Maintainers, do you think that's practical and desirable?
I think I have super powers all repos to do the switch when github is
ready to make us the switch. Practical no, there will be disruptions...
desirable no, it´s extra work, but the point is that it is doable.
If the ClusterLabs projects switch together I might take the opportunity
to make the switch in gfs2-utils.git at the same time, for consistency.
Is there a single name that makes sense for all projects? "next",
"development" or "unstable" captures how pacemaker uses master, not
sure about other projects. "main" is generic enough for all projects,
but so generic it doesn't give an idea of how it's used. Or we could go
for something distinctive like fedora's "rawhide" or suse's
"tumbleweed".
"main" works for me, it seems to be the most widely adopted alternative
thanks to Github, so its purpose will be clear by convention. That said,
it doesn't matter too much as long as the remote HEAD is set to the new
branch.
I would go for main and follow github recommendations. They are putting
automatic redirects in place to smooth the transition and we can avoid
spending time finding a name that won´t offend some delicate soul over
the internet.
Another question is how to do the switch without causing confusion the
next time someone pulls. It might be safest to simply create the main
branch and delete the master branch (rather than, say, replacing all of
the content in master with an explanatory note). That way a 'git pull'
gives a hint of the change and no messy conflicts:
$ git pull
From /tmp/gittest/upstream
* [new branch] main -> origin/main
Your configuration specifies to merge with the ref 'refs/heads/master'
from the remote, but no such ref was fetched.
Maybe also push a 'master_is_now_main' tag annotated with 'use git
branch -u origin/main to fix tracking branches'. Or maybe that's
excessive :)
Let´s wait for github to put those in place for us. No point to
re-invent the wheel. Last blog I read they were working to do it at
infrastructure level and that would save us a lot of headaches and
complications.
IIRC they will add main branch automatically to new projects and
transition old ones. the master branch will be an automatic redirect to
main. Basically will solve 99% of our issues. git pull won´t break etc.
Cheers
Fabio
Cheers,
Andy
Since we are admin of all repositories, we can do it in one shot
without
too much pain and suffering in CI. It will require probably a day or
two
of CI downtime to rebuild the world as well.
Fabio
The change would not affect existing repositories/projects.
However I
am wondering if we should take the opportunity of the minor-
version
bump to do the same for Pacemaker. The impact on developers would
be a
one-time process for each checkout/fork:
https://wiki.clusterlabs.org/wiki/Pacemaker_2.1_Changes#Development_changes
In my opinion, this is a minor usage that many existing projects
will
not bother changing, but I do think that since all new projects
will
default to "main", sometime in the future any project still using
"master" will appear outdated to young developers.
We could use "main" or something else. Some projects are
switching to
names like "release", "stable", or "next" depending on how
they're
actually using the branch ("next" would be appropriate in
Pacemaker's
case).
This will probably go on for years, so I am fine with either
changing
it with 2.1.0 (since it has bigger changes than usual, and we can
get
ahead of the curve) or waiting until the dust settles and future
conventions are clearer.
Opinions?
I support this change whole heatedly. I'll leave it to others to
decide
what new word is best (though 'main' makes sense to me), but the
goal of
m
[Cluster-devel] [PATCHv2 dlm/next 2/3] fs: dlm: constify addr_compare
This patch just constify some function parameter which should be have a
read access only.
Signed-off-by: Alexander Aring
---
fs/dlm/lowcomms.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 9973293bfddcd..c23d794e82910 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -270,7 +270,8 @@ static struct dlm_node_addr *find_node_addr(int nodeid)
return NULL;
}
-static int addr_compare(struct sockaddr_storage *x, struct sockaddr_storage *y)
+static int addr_compare(const struct sockaddr_storage *x,
+ const struct sockaddr_storage *y)
{
switch (x->ss_family) {
case AF_INET: {
--
2.26.2
[Cluster-devel] [PATCHv2 dlm/next 3/3] fs: dlm: check on existing node address
This patch checks if we add twice the same address to a per node address
array. This should never be the case and we report -EEXIST to the user
space.
Signed-off-by: Alexander Aring
---
fs/dlm/lowcomms.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index c23d794e82910..8122eb5f2afb8 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -370,10 +370,25 @@ static int addr_to_nodeid(struct sockaddr_storage *addr,
int *nodeid)
return rv;
}
+/* caller need to held dlm_node_addrs_spin lock */
+static bool dlm_lowcomms_na_has_addr(const struct dlm_node_addr *na,
+const struct sockaddr_storage *addr)
+{
+ int i;
+
+ for (i = 0; i < na->addr_count; i++) {
+ if (addr_compare(na->addr[i], addr))
+ return true;
+ }
+
+ return false;
+}
+
int dlm_lowcomms_addr(int nodeid, struct sockaddr_storage *addr, int len)
{
struct sockaddr_storage *new_addr;
struct dlm_node_addr *new_node, *na;
+ bool ret;
new_node = kzalloc(sizeof(struct dlm_node_addr), GFP_NOFS);
if (!new_node)
@@ -398,6 +413,14 @@ int dlm_lowcomms_addr(int nodeid, struct sockaddr_storage
*addr, int len)
return 0;
}
+ ret = dlm_lowcomms_na_has_addr(na, addr);
+ if (ret) {
+ spin_unlock(&dlm_node_addrs_spin);
+ kfree(new_addr);
+ kfree(new_node);
+ return -EEXIST;
+ }
+
if (na->addr_count >= DLM_MAX_ADDR_COUNT) {
spin_unlock(&dlm_node_addrs_spin);
kfree(new_addr);
--
2.26.2
[Cluster-devel] [PATCHv2 dlm/next 0/3] fs: dlm: node address configuration fixes
Hi, I got reports of: kernel: dlm: TCP protocol can't handle multi-homed hosts, try SCTP there was some reconfiguration involed and my guess it that we left some dlm_local_addr array pointers in some dangled state. The first patch should fix the observed behaviour. The other patches is something what I thought can also happen, it just checks if we setup a node address twice, if this is the case we return -EEXIST. This is based on dlm/next with the previous submitted patch series. - Alex changes since v2: - remove deadlock situation in 3/3 - fix grammar in 1/3 commit msg Alexander Aring (3): fs: dlm: cleanup dlm_local_addr properly fs: dlm: constify addr_compare fs: dlm: check on existing node address fs/dlm/lowcomms.c | 30 -- 1 file changed, 28 insertions(+), 2 deletions(-) -- 2.26.2
[Cluster-devel] [PATCHv2 dlm/next 1/3] fs: dlm: cleanup dlm_local_addr properly
This patch assigns the dlm_local_addr entries to NULL after we freeing
the memory of the entry. This is required because the user can changed some
settings with less addresses than before and a NULL check on start
functionality will check on a dangled pointer.
Signed-off-by: Alexander Aring
---
fs/dlm/lowcomms.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 11e5e92148fda..9973293bfddcd 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -1248,8 +1248,10 @@ static void deinit_local(void)
{
int i;
- for (i = 0; i < dlm_local_count; i++)
+ for (i = 0; i < dlm_local_count; i++) {
kfree(dlm_local_addr[i]);
+ dlm_local_addr[i] = NULL;
+ }
}
/* Initialise SCTP socket and bind to all interfaces
--
2.26.2
Re: [Cluster-devel] [PATCH dlm/next 3/3] fs: dlm: check on existing node address
Hi,
On Tue, Oct 20, 2020 at 5:10 PM Alexander Aring wrote:
>
> This patch checks if we add twice the same address to a per node address
> array. This should never be the case and we report -EEXIST to the user
> space.
>
> Signed-off-by: Alexander Aring
> ---
> fs/dlm/lowcomms.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
> index c23d794e82910..0dc651676dfa1 100644
> --- a/fs/dlm/lowcomms.c
> +++ b/fs/dlm/lowcomms.c
> @@ -370,10 +370,28 @@ static int addr_to_nodeid(struct sockaddr_storage
> *addr, int *nodeid)
> return rv;
> }
>
> +static bool dlm_lowcomms_na_has_addr(const struct dlm_node_addr *na,
> +const struct sockaddr_storage *addr)
> +{
> + int i;
> +
> + spin_lock(&dlm_node_addrs_spin);
> + for (i = 0; i < na->addr_count; i++) {
> + if (addr_compare(na->addr[i], addr)) {
> + spin_unlock(&dlm_node_addrs_spin);
> + return true;
> + }
> + }
> + spin_unlock(&dlm_node_addrs_spin);
grml, this lock is already held when calling that function, I need to
remove the lock and make some comment that this lock needs to be held
when the user calls it.
Sorry, I will send a v2.
- Alex
[Cluster-devel] [PATCH dlm/next 3/3] fs: dlm: check on existing node address
This patch checks if we add twice the same address to a per node address
array. This should never be the case and we report -EEXIST to the user
space.
Signed-off-by: Alexander Aring
---
fs/dlm/lowcomms.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index c23d794e82910..0dc651676dfa1 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -370,10 +370,28 @@ static int addr_to_nodeid(struct sockaddr_storage *addr,
int *nodeid)
return rv;
}
+static bool dlm_lowcomms_na_has_addr(const struct dlm_node_addr *na,
+const struct sockaddr_storage *addr)
+{
+ int i;
+
+ spin_lock(&dlm_node_addrs_spin);
+ for (i = 0; i < na->addr_count; i++) {
+ if (addr_compare(na->addr[i], addr)) {
+ spin_unlock(&dlm_node_addrs_spin);
+ return true;
+ }
+ }
+ spin_unlock(&dlm_node_addrs_spin);
+
+ return false;
+}
+
int dlm_lowcomms_addr(int nodeid, struct sockaddr_storage *addr, int len)
{
struct sockaddr_storage *new_addr;
struct dlm_node_addr *new_node, *na;
+ bool ret;
new_node = kzalloc(sizeof(struct dlm_node_addr), GFP_NOFS);
if (!new_node)
@@ -398,6 +416,14 @@ int dlm_lowcomms_addr(int nodeid, struct sockaddr_storage
*addr, int len)
return 0;
}
+ ret = dlm_lowcomms_na_has_addr(na, addr);
+ if (ret) {
+ spin_unlock(&dlm_node_addrs_spin);
+ kfree(new_addr);
+ kfree(new_node);
+ return -EEXIST;
+ }
+
if (na->addr_count >= DLM_MAX_ADDR_COUNT) {
spin_unlock(&dlm_node_addrs_spin);
kfree(new_addr);
--
2.26.2
[Cluster-devel] [PATCH dlm/next 2/3] fs: dlm: constify addr_compare
This patch just constify some function parameter which should be have a
read access only.
Signed-off-by: Alexander Aring
---
fs/dlm/lowcomms.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 9973293bfddcd..c23d794e82910 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -270,7 +270,8 @@ static struct dlm_node_addr *find_node_addr(int nodeid)
return NULL;
}
-static int addr_compare(struct sockaddr_storage *x, struct sockaddr_storage *y)
+static int addr_compare(const struct sockaddr_storage *x,
+ const struct sockaddr_storage *y)
{
switch (x->ss_family) {
case AF_INET: {
--
2.26.2
[Cluster-devel] [PATCH dlm/next 0/3] fs: dlm: node address configuration fixes
Hi, I got reports of: kernel: dlm: TCP protocol can't handle multi-homed hosts, try SCTP there was some reconfiguration involed and my guess it that we left some dlm_local_addr array pointers in some dangled state. The first patch should fix the observed behaviour. The other patches is something what I thought can also happen, it just checks if we setup a node address twice, if this is the case we return -EEXIST. This is based on dlm/next with the previous submitted patch series. - Alex Alexander Aring (3): fs: dlm: cleanup dlm_local_addr properly fs: dlm: constify addr_compare fs: dlm: check on existing node address fs/dlm/lowcomms.c | 33 +++-- 1 file changed, 31 insertions(+), 2 deletions(-) -- 2.26.2
[Cluster-devel] [PATCH dlm/next 1/3] fs: dlm: cleanup dlm_local_addr properly
This patch assigns the dlm_local_addr entries to NULL after we freeing
the memory of the entry. This required because the user can changed some
settings with less addresses than before and a NULL check on start
functionality will check on a dangled pointer.
Signed-off-by: Alexander Aring
---
fs/dlm/lowcomms.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 11e5e92148fda..9973293bfddcd 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -1248,8 +1248,10 @@ static void deinit_local(void)
{
int i;
- for (i = 0; i < dlm_local_count; i++)
+ for (i = 0; i < dlm_local_count; i++) {
kfree(dlm_local_addr[i]);
+ dlm_local_addr[i] = NULL;
+ }
}
/* Initialise SCTP socket and bind to all interfaces
--
2.26.2
[Cluster-devel] [PATCH v3 2/3] gfs2: lookup local statfs inodes prior to journal recovery
We need to lookup the master statfs inode and the local statfs
inodes earlier in the mount process (in init_journal) so journal
recovery can use them when it attempts to recover the statfs info.
We lookup all the local statfs inodes and store them in a linked
list to allow a node to recover statfs info for other nodes in the
cluster.
Signed-off-by: Abhi Das
---
fs/gfs2/incore.h | 8 +++
fs/gfs2/ops_fstype.c | 133 +++
fs/gfs2/super.c | 31 +-
fs/gfs2/super.h | 3 +
4 files changed, 139 insertions(+), 36 deletions(-)
diff --git a/fs/gfs2/incore.h b/fs/gfs2/incore.h
index e34183e02a9e..0220f2b1d5bf 100644
--- a/fs/gfs2/incore.h
+++ b/fs/gfs2/incore.h
@@ -697,6 +697,13 @@ struct gfs2_pcpu_lkstats {
struct gfs2_lkstats lkstats[10];
};
+/* List of local (per node) statfs inodes */
+struct lcl_statfs_inode {
+ struct list_head si_list;
+ struct inode *si_sc_inode;
+ unsigned int si_jid; /* journal id this statfs inode corresponds to */
+};
+
struct gfs2_sbd {
struct super_block *sd_vfs;
struct gfs2_pcpu_lkstats __percpu *sd_lkstats;
@@ -748,6 +755,7 @@ struct gfs2_sbd {
struct inode *sd_jindex;
struct inode *sd_statfs_inode;
struct inode *sd_sc_inode;
+ struct list_head sd_sc_inodes_list;
struct inode *sd_qc_inode;
struct inode *sd_rindex;
struct inode *sd_quota_inode;
diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
index 03c33fc03c05..dc304f60b39a 100644
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -110,6 +110,8 @@ static struct gfs2_sbd *init_sbd(struct super_block *sb)
spin_lock_init(&sdp->sd_trunc_lock);
spin_lock_init(&sdp->sd_bitmap_lock);
+ INIT_LIST_HEAD(&sdp->sd_sc_inodes_list);
+
mapping = &sdp->sd_aspace;
address_space_init_once(mapping);
@@ -608,6 +610,90 @@ static int gfs2_jindex_hold(struct gfs2_sbd *sdp, struct
gfs2_holder *ji_gh)
return error;
}
+/**
+ * init_statfs - lookup and initialize master and local (per node)
+ * statfs inodes. This should be called after the jindex
+ * is initialized in init_journal() and before
+ * gfs2_journal_recovery() is called because we need to
+ * be able to write to these inodes during recovery.
+ * @sdp: The GFS2 superblock
+ *
+ * Returns: errno
+ */
+static int init_statfs(struct gfs2_sbd *sdp)
+{
+ int error = 0;
+ struct inode *master = d_inode(sdp->sd_master_dir);
+ struct inode *pn = NULL;
+ char buf[30];
+ struct gfs2_jdesc *jd;
+ struct gfs2_inode *ip;
+
+ sdp->sd_statfs_inode = gfs2_lookup_simple(master, "statfs");
+ if (IS_ERR(sdp->sd_statfs_inode)) {
+ error = PTR_ERR(sdp->sd_statfs_inode);
+ fs_err(sdp, "can't read in statfs inode: %d\n", error);
+ goto fail;
+ }
+
+ pn = gfs2_lookup_simple(master, "per_node");
+ if (IS_ERR(pn)) {
+ error = PTR_ERR(pn);
+ fs_err(sdp, "can't find per_node directory: %d\n", error);
+ goto put_statfs;
+ }
+
+ /* For each jid, lookup the corresponding local statfs inode in the
+* per_node metafs directory and save it in the sdp->sd_sc_inodes_list.
*/
+ list_for_each_entry(jd, &sdp->sd_jindex_list, jd_list) {
+ struct lcl_statfs_inode *lsi =
+ kmalloc(sizeof(struct lcl_statfs_inode), GFP_NOFS);
+ if (!lsi) {
+ error = -ENOMEM;
+ goto free_lcl;
+ }
+ sprintf(buf, "statfs_change%u", jd->jd_jid);
+ lsi->si_sc_inode = gfs2_lookup_simple(pn, buf);
+ if (IS_ERR(lsi->si_sc_inode)) {
+ error = PTR_ERR(lsi->si_sc_inode);
+ fs_err(sdp, "can't find local \"sc\" file#%u: %d\n",
+ jd->jd_jid, error);
+ goto free_lcl;
+ }
+ lsi->si_jid = jd->jd_jid;
+ if (jd->jd_jid == sdp->sd_jdesc->jd_jid)
+ sdp->sd_sc_inode = lsi->si_sc_inode;
+
+ list_add_tail(&lsi->si_list, &sdp->sd_sc_inodes_list);
+ }
+
+ iput(pn);
+ ip = GFS2_I(sdp->sd_sc_inode);
+ error = gfs2_glock_nq_init(ip->i_gl, LM_ST_EXCLUSIVE, 0,
+ &sdp->sd_sc_gh);
+ if (error) {
+ fs_err(sdp, "can't lock local \"sc\" file: %d\n", error);
+ goto free_lcl;
+ }
+ return 0;
+
+free_lcl:
+ free_lcl_statfs_inodes(sdp);
+ iput(pn);
+put_statfs:
+ iput(sdp->sd_statfs_inode);
+fail:
+ return error;
+}
+
+/* Uninitialize and free up memory used by the list of statfs inodes */
+static void uninit_statfs(struct gfs2_sbd *sdp)
+{
+ gfs2_glock_dq_uninit(&sdp->sd_sc_gh);
+ fre
[Cluster-devel] [PATCH v3 3/3] gfs2: Recover statfs info in journal head
Apply the outstanding statfs changes in the journal head to the
master statfs file. Zero out the local statfs file for good measure.
Previously, statfs updates would be read in from the local statfs inode and
synced to the master statfs inode during recovery.
We now use the statfs updates in the journal head to update the master statfs
inode instead of reading in from the local statfs inode. To preserve backward
compatibility with kernels that can't do this, we still need to keep the
local statfs inode up to date by writing changes to it. At some point in the
future, we can do away with the local statfs inodes altogether and keep the
statfs changes solely in the journal.
Signed-off-by: Abhi Das
---
fs/gfs2/lops.c | 2 +-
fs/gfs2/lops.h | 1 +
fs/gfs2/recovery.c | 104 +
3 files changed, 106 insertions(+), 1 deletion(-)
diff --git a/fs/gfs2/lops.c b/fs/gfs2/lops.c
index ed1da4323967..ed69298dd824 100644
--- a/fs/gfs2/lops.c
+++ b/fs/gfs2/lops.c
@@ -823,7 +823,7 @@ static int buf_lo_scan_elements(struct gfs2_jdesc *jd, u32
start,
*
*/
-static void gfs2_meta_sync(struct gfs2_glock *gl)
+void gfs2_meta_sync(struct gfs2_glock *gl)
{
struct address_space *mapping = gfs2_glock2aspace(gl);
struct gfs2_sbd *sdp = gl->gl_name.ln_sbd;
diff --git a/fs/gfs2/lops.h b/fs/gfs2/lops.h
index 9c5e4e491e03..4a3d8aecdf82 100644
--- a/fs/gfs2/lops.h
+++ b/fs/gfs2/lops.h
@@ -27,6 +27,7 @@ extern void gfs2_log_submit_bio(struct bio **biop, int opf);
extern void gfs2_pin(struct gfs2_sbd *sdp, struct buffer_head *bh);
extern int gfs2_find_jhead(struct gfs2_jdesc *jd,
struct gfs2_log_header_host *head, bool keep_cache);
+extern void gfs2_meta_sync(struct gfs2_glock *gl);
static inline unsigned int buf_limit(struct gfs2_sbd *sdp)
{
diff --git a/fs/gfs2/recovery.c b/fs/gfs2/recovery.c
index a8bb17e355b8..caaa35bd6349 100644
--- a/fs/gfs2/recovery.c
+++ b/fs/gfs2/recovery.c
@@ -296,6 +296,109 @@ static void gfs2_recovery_done(struct gfs2_sbd *sdp,
unsigned int jid,
sdp->sd_lockstruct.ls_ops->lm_recovery_result(sdp, jid,
message);
}
+/**
+ * update_statfs_inode - Update the master statfs inode or zero out the local
+ * statfs inode for a given journal.
+ * @jd: The journal
+ * @head: If NULL, @inode is the local statfs inode and we need to zero it out.
+ *Otherwise, it @head contains the statfs change info that needs to be
+ *synced to the master statfs inode (pointed to by @inode).
+ * @inode: statfs inode to update.
+ */
+static int update_statfs_inode(struct gfs2_jdesc *jd,
+ struct gfs2_log_header_host *head,
+ struct inode *inode)
+{
+ struct gfs2_sbd *sdp = GFS2_SB(jd->jd_inode);
+ struct gfs2_inode *ip;
+ struct buffer_head *bh;
+ struct gfs2_statfs_change_host sc;
+ int error = 0;
+
+ BUG_ON(!inode);
+ ip = GFS2_I(inode);
+
+ error = gfs2_meta_inode_buffer(ip, &bh);
+ if (error)
+ goto out;
+
+ spin_lock(&sdp->sd_statfs_spin);
+
+ if (head) { /* Update the master statfs inode */
+ gfs2_statfs_change_in(&sc, bh->b_data + sizeof(struct
gfs2_dinode));
+ sc.sc_total += head->lh_local_total;
+ sc.sc_free += head->lh_local_free;
+ sc.sc_dinodes += head->lh_local_dinodes;
+ gfs2_statfs_change_out(&sc, bh->b_data + sizeof(struct
gfs2_dinode));
+
+ fs_info(sdp, "jid=%u: Updated master statfs Total:%lld, "
+ "Free:%lld, Dinodes:%lld after change "
+ "[%+lld,%+lld,%+lld]\n", jd->jd_jid, sc.sc_total,
+ sc.sc_free, sc.sc_dinodes, head->lh_local_total,
+ head->lh_local_free, head->lh_local_dinodes);
+ } else { /* Zeroing out the local statfs inode */
+ memset(bh->b_data + sizeof(struct gfs2_dinode), 0,
+ sizeof(struct gfs2_statfs_change));
+ /* If it's our own journal, reset any in-memory changes too */
+ if (jd->jd_jid == sdp->sd_lockstruct.ls_jid) {
+ memset(&sdp->sd_statfs_local, 0,
+ sizeof(struct gfs2_statfs_change_host));
+ }
+ }
+ spin_unlock(&sdp->sd_statfs_spin);
+
+ mark_buffer_dirty(bh);
+ brelse(bh);
+ gfs2_meta_sync(ip->i_gl);
+
+out:
+ return error;
+}
+
+/**
+ * recover_local_statfs - Update the master and local statfs changes for this
+ *journal.
+ *
+ * Previously, statfs updates would be read in from the local statfs inode and
+ * synced to the master statfs inode during recovery.
+ *
+ * We now use the statfs updates in the journal head to update the master
statfs
+ * inode instead of reading in from the local statfs inode. To preserve
backward
+ * co
[Cluster-devel] [PATCH v3 0/3] gfs2: local statfs improvements
This patchset allows gfs2 to sync statfs info from the journal to the master statfs file during a log flush or during recovery. We still write to the local statfs file to allow older versions to recover the statfs info of newer kernels with this patchset. This version addresses the bug Andreas found with xfstests:generic/034. Turns out we weren't looking up the statfs inodes early enough in the mount process. I also added some comments in the code. Abhi Das (3): gfs2: Add fields for statfs info in struct gfs2_log_header_host gfs2: lookup local statfs inodes prior to journal recovery gfs2: Recover statfs info in journal head fs/gfs2/incore.h | 12 fs/gfs2/lops.c | 2 +- fs/gfs2/lops.h | 1 + fs/gfs2/ops_fstype.c | 133 +++ fs/gfs2/recovery.c | 108 +++ fs/gfs2/super.c | 33 ++- fs/gfs2/super.h | 5 ++ 7 files changed, 256 insertions(+), 38 deletions(-) -- 2.20.1
[Cluster-devel] [PATCH v3 1/3] gfs2: Add fields for statfs info in struct gfs2_log_header_host
And read these in __get_log_header() from the log header.
Also make gfs2_statfs_change_out() non-static so it can be used
outside of super.c
Signed-off-by: Abhi Das
---
fs/gfs2/incore.h | 4
fs/gfs2/recovery.c | 4
fs/gfs2/super.c| 2 +-
fs/gfs2/super.h| 2 ++
4 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/fs/gfs2/incore.h b/fs/gfs2/incore.h
index c3ca9b8382ec..e34183e02a9e 100644
--- a/fs/gfs2/incore.h
+++ b/fs/gfs2/incore.h
@@ -41,6 +41,10 @@ struct gfs2_log_header_host {
u32 lh_flags; /* GFS2_LOG_HEAD_... */
u32 lh_tail;/* Block number of log tail */
u32 lh_blkno;
+
+ s64 lh_local_total;
+ s64 lh_local_free;
+ s64 lh_local_dinodes;
};
/*
diff --git a/fs/gfs2/recovery.c b/fs/gfs2/recovery.c
index 390ea79d682c..a8bb17e355b8 100644
--- a/fs/gfs2/recovery.c
+++ b/fs/gfs2/recovery.c
@@ -144,6 +144,10 @@ int __get_log_header(struct gfs2_sbd *sdp, const struct
gfs2_log_header *lh,
head->lh_tail = be32_to_cpu(lh->lh_tail);
head->lh_blkno = be32_to_cpu(lh->lh_blkno);
+ head->lh_local_total = be64_to_cpu(lh->lh_local_total);
+ head->lh_local_free = be64_to_cpu(lh->lh_local_free);
+ head->lh_local_dinodes = be64_to_cpu(lh->lh_local_dinodes);
+
return 0;
}
/**
diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
index 8e250ec42e91..e17961ea994d 100644
--- a/fs/gfs2/super.c
+++ b/fs/gfs2/super.c
@@ -230,7 +230,7 @@ void gfs2_statfs_change_in(struct gfs2_statfs_change_host
*sc, const void *buf)
sc->sc_dinodes = be64_to_cpu(str->sc_dinodes);
}
-static void gfs2_statfs_change_out(const struct gfs2_statfs_change_host *sc,
void *buf)
+void gfs2_statfs_change_out(const struct gfs2_statfs_change_host *sc, void
*buf)
{
struct gfs2_statfs_change *str = buf;
diff --git a/fs/gfs2/super.h b/fs/gfs2/super.h
index 51900554ed81..ed4f5cb29074 100644
--- a/fs/gfs2/super.h
+++ b/fs/gfs2/super.h
@@ -37,6 +37,8 @@ extern void gfs2_statfs_change(struct gfs2_sbd *sdp, s64
total, s64 free,
s64 dinodes);
extern void gfs2_statfs_change_in(struct gfs2_statfs_change_host *sc,
const void *buf);
+extern void gfs2_statfs_change_out(const struct gfs2_statfs_change_host *sc,
+ void *buf);
extern void update_statfs(struct gfs2_sbd *sdp, struct buffer_head *m_bh,
struct buffer_head *l_bh);
extern int gfs2_statfs_sync(struct super_block *sb, int type);
--
2.20.1
Re: [Cluster-devel] [ClusterLabs Developers] Pacemaker 2.1.0: Should we rename the master branch?
[CC+ cluster-devel]
On 19/10/2020 23:59, Ken Gaillot wrote:
On Mon, 2020-10-19 at 07:19 +0200, Fabio M. Di Nitto wrote:
Hi Ken,
On 10/2/2020 8:02 PM, Digimer wrote:
On 2020-10-02 1:12 p.m., Ken Gaillot wrote:
Hi all,
I sent a message to the us...@clusterlabs.org list about
releasing
Pacemaker 2.1.0 next year.
Coincidentally, there is a plan in the git and Github communities
to
change the default git branch from "master" to "main":
https://github.com/github/renaming
The rationale for the change is not the specific meaning as used
in
branching, but rather to avoid any possibility of fostering an
exclusionary environment, and to replace generic metaphors with
something more obvious (especially to non-native English
speakers).
No objections to the change, but please let´s coordinate the change
across all HA projects at once, or CI is going to break badly as the
concept of master branch is embedded everywhere and not per-project.
Presumably this would be all the projects built by jenkins?
booth
corosync
fence-agents
fence-virt
knet
libqb
pacemaker
pcs
qdevice
resource-agents
sbd
Maintainers, do you think that's practical and desirable?
If the ClusterLabs projects switch together I might take the opportunity
to make the switch in gfs2-utils.git at the same time, for consistency.
Is there a single name that makes sense for all projects? "next",
"development" or "unstable" captures how pacemaker uses master, not
sure about other projects. "main" is generic enough for all projects,
but so generic it doesn't give an idea of how it's used. Or we could go
for something distinctive like fedora's "rawhide" or suse's
"tumbleweed".
"main" works for me, it seems to be the most widely adopted alternative
thanks to Github, so its purpose will be clear by convention. That said,
it doesn't matter too much as long as the remote HEAD is set to the new
branch.
Another question is how to do the switch without causing confusion the
next time someone pulls. It might be safest to simply create the main
branch and delete the master branch (rather than, say, replacing all of
the content in master with an explanatory note). That way a 'git pull'
gives a hint of the change and no messy conflicts:
$ git pull
From /tmp/gittest/upstream
* [new branch] main -> origin/main
Your configuration specifies to merge with the ref 'refs/heads/master'
from the remote, but no such ref was fetched.
Maybe also push a 'master_is_now_main' tag annotated with 'use git
branch -u origin/main to fix tracking branches'. Or maybe that's
excessive :)
Cheers,
Andy
Since we are admin of all repositories, we can do it in one shot
without
too much pain and suffering in CI. It will require probably a day or
two
of CI downtime to rebuild the world as well.
Fabio
The change would not affect existing repositories/projects.
However I
am wondering if we should take the opportunity of the minor-
version
bump to do the same for Pacemaker. The impact on developers would
be a
one-time process for each checkout/fork:
https://wiki.clusterlabs.org/wiki/Pacemaker_2.1_Changes#Development_changes
In my opinion, this is a minor usage that many existing projects
will
not bother changing, but I do think that since all new projects
will
default to "main", sometime in the future any project still using
"master" will appear outdated to young developers.
We could use "main" or something else. Some projects are
switching to
names like "release", "stable", or "next" depending on how
they're
actually using the branch ("next" would be appropriate in
Pacemaker's
case).
This will probably go on for years, so I am fine with either
changing
it with 2.1.0 (since it has bigger changes than usual, and we can
get
ahead of the curve) or waiting until the dust settles and future
conventions are clearer.
Opinions?
I support this change whole heatedly. I'll leave it to others to
decide
what new word is best (though 'main' makes sense to me), but the
goal of
moving away from 'master/slave' is well worthwhile and appreciated.
[Cluster-devel] [PATCH] gfs2: use helper macro abs()
Use helper macro abs() to simplify the "x >= y || x <= -y" cmp.
Signed-off-by: Xianting Tian
---
fs/gfs2/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
index 9f4d9e7be..05eb709de 100644
--- a/fs/gfs2/super.c
+++ b/fs/gfs2/super.c
@@ -304,7 +304,7 @@ void gfs2_statfs_change(struct gfs2_sbd *sdp, s64 total,
s64 free,
if (sdp->sd_args.ar_statfs_percent) {
x = 100 * l_sc->sc_free;
y = m_sc->sc_free * sdp->sd_args.ar_statfs_percent;
- if (x >= y || x <= -y)
+ if (abs(x) >= y)
need_sync = 1;
}
spin_unlock(&sdp->sd_statfs_spin);
--
2.17.1
