All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern-PCqxUs/MD9bYtjvyW6yDsg@public.gmane.org>
To: Vyacheslav Dubeyko <slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org>
Cc: Ryusuke Konishi
	<konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>,
	linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Clemens Eisserer
	<linuxhippy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH v5 2/2] nilfs2: use atomic_long_t type for inodes_count and blocks_count fields in nilfs_root struct
Date: Fri, 24 May 2013 13:54:06 -0400	[thread overview]
Message-ID: <20130524175406.GD30270@logfs.org> (raw)
In-Reply-To: <1369402372.2235.23.camel@slavad-ubuntu>

On Fri, 24 May 2013 17:32:52 +0400, Vyacheslav Dubeyko wrote:
>
> Subject: [PATCH v5 2/2] nilfs2: use atomic_long_t type for inodes_count
...
> The cp_inodes_count and cp_blocks_count are represented as
> __le64 type in on-disk structure (struct nilfs_checkpoint).

Isn't atomic_long_t defined to be 32bit on 32bit architectures?

Jörn

--
What one programmer can do in one month, two programmers can do in two months.
-- Fred Brooks
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: "Jörn Engel" <joern-PCqxUs/MD9bYtjvyW6yDsg@public.gmane.org>
To: Vyacheslav Dubeyko <slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org>
Cc: Ryusuke Konishi
	<konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>,
	linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Clemens Eisserer
	<linuxhippy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH v5 2/2] nilfs2: use atomic_long_t type for inodes_count and blocks_count fields in nilfs_root struct
Date: Fri, 24 May 2013 13:54:06 -0400	[thread overview]
Message-ID: <20130524175406.GD30270@logfs.org> (raw)
In-Reply-To: <1369402372.2235.23.camel@slavad-ubuntu>

On Fri, 24 May 2013 17:32:52 +0400, Vyacheslav Dubeyko wrote:
>
> Subject: [PATCH v5 2/2] nilfs2: use atomic_long_t type for inodes_count
...
> The cp_inodes_count and cp_blocks_count are represented as
> __le64 type in on-disk structure (struct nilfs_checkpoint).

Isn't atomic_long_t defined to be 32bit on 32bit architectures?

Jörn

--
What one programmer can do in one month, two programmers can do in two months.
-- Fred Brooks
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2013-05-24 17:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-24 13:32 [PATCH v5 2/2] nilfs2: use atomic_long_t type for inodes_count and blocks_count fields in nilfs_root struct Vyacheslav Dubeyko
2013-05-24 17:43 ` Ryusuke Konishi
2013-05-24 17:54 ` Jörn Engel [this message]
2013-05-24 17:54   ` Jörn Engel
     [not found]   ` <20130524175406.GD30270-PCqxUs/MD9bYtjvyW6yDsg@public.gmane.org>
2013-05-24 19:30     ` Vyacheslav Dubeyko
2013-05-24 19:01       ` Jörn Engel
     [not found]         ` <20130524190146.GF30270-PCqxUs/MD9bYtjvyW6yDsg@public.gmane.org>
2013-05-24 22:01           ` Vyacheslav Dubeyko
2013-05-24 21:37             ` Jörn Engel
2013-05-25  3:33               ` Ryusuke Konishi
     [not found]                 ` <20130525.123303.412805468.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2013-05-26 12:18                   ` Vyacheslav Dubeyko
     [not found]                     ` <DF00B7E3-7352-4AEC-B0D9-AB7E624E5793-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org>
2013-05-26 14:43                       ` Ryusuke Konishi

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=20130524175406.GD30270@logfs.org \
    --to=joern-pcqxus/md9bytjvyw6ydsg@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org \
    --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linuxhippy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org \
    /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.