All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mingming Cao <cmm@us.ibm.com>
To: Kalpak Shah <kalpak@clusterfs.com>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>,
	Andreas Dilger <adilger@clusterfs.com>,
	TheodoreTso <tytso@mit.edu>,
	Dave Kleikamp <shaggy@linux.vnet.ibm.com>,
	Eric Sandeen <sandeen@redhat.com>
Subject: Re: [PATCH] Add i_version_hi for 64-bit version
Date: Mon, 02 Apr 2007 14:47:38 -0700	[thread overview]
Message-ID: <1175550458.4333.13.camel@localhost.localdomain> (raw)
In-Reply-To: <1174212819.3282.10.camel@garfield>

On Sun, 2007-03-18 at 15:43 +0530, Kalpak Shah wrote:
> Hi,
> 
> This patch adds a 32-bit i_version_hi field to ext4_inode, which can be used for 64-bit inode versions. This field will store the higher 32 bits of the version, while Jean Noel's patch has added support to store the lower 32-bits in osd1.linux1.l_i_version.
> 
> Signed-off-by: Andreas Dilger <adilger@clusterfs.com>
> Signed-off-by: Kalpak Shah <kalpak@clusterfs.com>
> 
> Index: linux-2.6.20/include/linux/ext4_fs.h
> ===================================================================
> --- linux-2.6.20.orig/include/linux/ext4_fs.h
> +++ linux-2.6.20/include/linux/ext4_fs.h
> @@ -336,6 +336,7 @@ struct ext4_inode {
>         __le32  i_atime_extra;  /* extra Access time      (nsec << 2 | epoch) */
>         __le32  i_crtime;       /* File Creation time */
>         __le32  i_crtime_extra; /* extra File Creation time (nsec << 2 | epoch) */
> +       __u32   i_version_hi;   /* high 32 bits for 64-bit version */
>  };
> 

Any reason not using __le32 for the i_version_hi?


Thanks,
Mingming

  parent reply	other threads:[~2007-04-02 21:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-18 10:13 [PATCH] Add i_version_hi for 64-bit version Kalpak Shah
2007-03-19 15:34 ` Dave Kleikamp
2007-04-02 21:47 ` Mingming Cao [this message]
2007-04-02 23:29   ` Andreas Dilger
  -- strict thread matches above, loose matches on Subject: below --
2007-04-03  6:56 Kalpak Shah

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=1175550458.4333.13.camel@localhost.localdomain \
    --to=cmm@us.ibm.com \
    --cc=adilger@clusterfs.com \
    --cc=kalpak@clusterfs.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=shaggy@linux.vnet.ibm.com \
    --cc=tytso@mit.edu \
    /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.