Btrfs stores generation numbers as 64bit numbers, which means we have to
carry around a u64 in our incore inode in addition to setting i_generation.
So convert to a u64 so btrfs can kill it''s incore generation. Thanks,
Signed-off-by: Josef Bacik <josef@redhat.com>
---
include/linux/fs.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 9be896d..40564e0 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -831,7 +831,7 @@ struct inode {
struct cdev *i_cdev;
};
- __u32 i_generation;
+ u64 i_generation;
#ifdef CONFIG_FSNOTIFY
__u32 i_fsnotify_mask; /* all events this inode cares about */
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe
linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 11, 2012 at 04:42:48PM -0400, Josef Bacik wrote:> Btrfs stores generation numbers as 64bit numbers, which means we have to > carry around a u64 in our incore inode in addition to setting i_generation. > So convert to a u64 so btrfs can kill it''s incore generation. Thanks, > > Signed-off-by: Josef Bacik <josef@redhat.com> > --- > include/linux/fs.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 9be896d..40564e0 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -831,7 +831,7 @@ struct inode { > struct cdev *i_cdev; > }; > > - __u32 i_generation; > + u64 i_generation;Why was this using __u32 instead of u32? -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2012/4/11 Josef Bacik <josef@redhat.com>:> Btrfs stores generation numbers as 64bit numbers, which means we have to > carry around a u64 in our incore inode in addition to setting i_generation. > So convert to a u64 so btrfs can kill it''s incore generation. Thanks, > > Signed-off-by: Josef Bacik <josef@redhat.com> > --- > include/linux/fs.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 9be896d..40564e0 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -831,7 +831,7 @@ struct inode { > struct cdev *i_cdev; > }; > > - __u32 i_generation; > + u64 i_generation; > > #ifdef CONFIG_FSNOTIFY > __u32 i_fsnotify_mask; /* all events this inode cares about */ > -- > 1.7.7.6This patch can have several impact on other fs. Only to do an example you can see the code in ioctl of ext4. I haven''t got study the code but the ioctl returns a long, but on 32bit system, long means 4 bytes, so how we can return i_generation with ioctl? Marco -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 12, 2012 at 08:46:14AM +0200, Marco Stornelli wrote:> 2012/4/11 Josef Bacik <josef@redhat.com>: > > Btrfs stores generation numbers as 64bit numbers, which means we have to > > carry around a u64 in our incore inode in addition to setting i_generation. > > So convert to a u64 so btrfs can kill it''s incore generation. Thanks, > > > > Signed-off-by: Josef Bacik <josef@redhat.com> > > --- > > include/linux/fs.h | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/include/linux/fs.h b/include/linux/fs.h > > index 9be896d..40564e0 100644 > > --- a/include/linux/fs.h > > +++ b/include/linux/fs.h > > @@ -831,7 +831,7 @@ struct inode { > > struct cdev *i_cdev; > > }; > > > > - __u32 i_generation; > > + u64 i_generation; > > > > #ifdef CONFIG_FSNOTIFY > > __u32 i_fsnotify_mask; /* all events this inode cares about */ > > -- > > 1.7.7.6 > > This patch can have several impact on other fs. Only to do an example > you can see the code in ioctl of ext4. I haven''t got study the code > but the ioctl returns a long, but on 32bit system, long means 4 bytes, > so how we can return i_generation with ioctl? >Thanks for pointing this out, I will fix ext4 up and look to see if anybody else does something similar, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 12, 2012 at 08:46:14AM +0200, Marco Stornelli wrote:> 2012/4/11 Josef Bacik <josef@redhat.com>: > > Btrfs stores generation numbers as 64bit numbers, which means we have to > > carry around a u64 in our incore inode in addition to setting i_generation. > > So convert to a u64 so btrfs can kill it''s incore generation. Thanks, > > > > Signed-off-by: Josef Bacik <josef@redhat.com> > > --- > > include/linux/fs.h | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/include/linux/fs.h b/include/linux/fs.h > > index 9be896d..40564e0 100644 > > --- a/include/linux/fs.h > > +++ b/include/linux/fs.h > > @@ -831,7 +831,7 @@ struct inode { > > struct cdev *i_cdev; > > }; > > > > - __u32 i_generation; > > + u64 i_generation; > > > > #ifdef CONFIG_FSNOTIFY > > __u32 i_fsnotify_mask; /* all events this inode cares about */ > > -- > > 1.7.7.6 > > This patch can have several impact on other fs. Only to do an example > you can see the code in ioctl of ext4. I haven''t got study the code > but the ioctl returns a long, but on 32bit system, long means 4 bytes, > so how we can return i_generation with ioctl?So looking through everybody I''d have to convert a bunch of cpu_to_le32 to (u32)cpu_to_le64 and some other such crap which I''m not terribly interested in doing, I don''t care _that_ much about saving 8 bytes, so I''ll just drop this for now. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 11, 2012 at 04:42:48PM -0400, Josef Bacik wrote:> Btrfs stores generation numbers as 64bit numbers, which means we have to > carry around a u64 in our incore inode in addition to setting i_generation. > So convert to a u64 so btrfs can kill it''s incore generation. Thanks, > > Signed-off-by: Josef Bacik <josef@redhat.com>Why is btrfs using a 64-bit generation number, out of curiosity? The only user of the inode generation number as far as I can tell is NFS, and even NFSv4 is using a 32-bit generation number.... - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 12, 2012 at 03:42:17PM -0400, Ted Ts''o wrote:> On Wed, Apr 11, 2012 at 04:42:48PM -0400, Josef Bacik wrote: > > Btrfs stores generation numbers as 64bit numbers, which means we have to > > carry around a u64 in our incore inode in addition to setting i_generation. > > So convert to a u64 so btrfs can kill it''s incore generation. Thanks, > > > > Signed-off-by: Josef Bacik <josef@redhat.com> > > Why is btrfs using a 64-bit generation number, out of curiosity? The > only user of the inode generation number as far as I can tell is NFS, > and even NFSv4 is using a 32-bit generation number.... >It''s just tied to our transaction id #''s which are 64bit, no super awesome reason or anything. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html