Transpose parent_objectid and parent_gen in struct btrfs_fid so that gen and
parent_gen (both u32) are adjacent, thus packing nicely between the u64
members.
This would seem to be reasonable as the parent generation number is always
used if the parent objectid is.
Signed-off-by: David Howells <[email protected]>
---
fs/btrfs/export.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/export.h b/fs/btrfs/export.h
index 074348a..319cc6e 100644
--- a/fs/btrfs/export.h
+++ b/fs/btrfs/export.h
@@ -10,8 +10,8 @@ struct btrfs_fid {
u64 root_objectid;
u32 gen;
- u64 parent_objectid;
u32 parent_gen;
+ u64 parent_objectid;
u64 parent_root_objectid;
} __attribute__ ((packed));
On Wed, 2009-03-18 at 16:16 +0000, David Howells wrote:
> Transpose parent_objectid and parent_gen in struct btrfs_fid so that gen and
> parent_gen (both u32) are adjacent, thus packing nicely between the u64
> members.
>
> This would seem to be reasonable as the parent generation number is always
> used if the parent objectid is.
>
Won't this confuse any handles the clients already have if the server
reboots with the new handle format?
-chris
Chris Mason <[email protected]> wrote:
> Won't this confuse any handles the clients already have if the server
> reboots with the new handle format?
Perhaps, but it's probably early enough in BTRFS's life to get away with it.
David
On Wed, 2009-03-18 at 17:05 +0000, David Howells wrote:
> Chris Mason <[email protected]> wrote:
>
> > Won't this confuse any handles the clients already have if the server
> > reboots with the new handle format?
>
> Perhaps, but it's probably early enough in BTRFS's life to get away with it.
True. It's not that hard to handle compatibility if we really care,
either.
But this struct is packed anyway -- we're not changing much on the wire;
it's just a case of how efficient it is to load that single uint64_t
from an unaligned location. Is that _really_ something we're ever going
to notice?
--
David Woodhouse Open Source Technology Centre
[email protected] Intel Corporation
David Woodhouse <[email protected]> wrote:
> But this struct is packed anyway -- we're not changing much on the wire;
> it's just a case of how efficient it is to load that single uint64_t
> from an unaligned location. Is that _really_ something we're ever going
> to notice?
If the CPU doing the load/store throws a misalignment exception or just
ignores the instruction because it's misaligned, it might make for interesting
debugging.
David
On Wed, 2009-03-18 at 17:38 +0000, David Howells wrote:
> If the CPU doing the load/store throws a misalignment exception or just
> ignores the instruction because it's misaligned, it might make for interesting
> debugging.
That would require a 64-bit CPU which doesn't naturally handle unaligned
loads, and a compiler bug.
--
David Woodhouse Open Source Technology Centre
[email protected] Intel Corporation