linux-kernel - Re: [PATCH 02/20] ceph: on-wire types

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0907160951420.7645@cobra.newdream.net>
Date:	Thu, 16 Jul 2009 09:58:32 -0700 (PDT)
From:	Sage Weil <sage@...dream.net>
To:	Andi Kleen <andi@...stfloor.org>
cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/20] ceph: on-wire types

On Thu, 16 Jul 2009, Andi Kleen wrote:
> Sage Weil <sage@...dream.net> writes:
> > +
> > +/*
> > + * Max file size is a policy choice; in reality we are limited
> > + * by 2^64.
> > + */
> > +#define CEPH_FILE_MAX_SIZE (1ULL << 40)   /* 1 TB */
> 
> Seems odd to hardcode this here.

It is.  It's just an arbitrary value to bound recovery time... I'll switch 
it a server-specified value.

> The way attribute packed is used in these files seems rather
> random and adhoc, sometimes it is, sometimes it isn't.

Not intentionally, it looks like it was missing on some structs 
that were already naturally aligned.  I'll add it everywhere.

> I assume you tested that 32bit and 64bit interoperability?

Yes.

> Is the file system supposed to be endian safe on the wire?

Yes, although I don't have access to any big endian machines, so it hasn't 
been tested.  We've been periodically running the code through sparse, 
though.

Thanks!
sage
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/