linux-kernel - Re: [osd-dev] [PATCH 1/9] exofs: osd Swiss army knife

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: <496CA89C.9090008@panasas.com>
Date:	Tue, 13 Jan 2009 16:43:40 +0200
From:	Boaz Harrosh <bharrosh@...asas.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Benny Halevy <bhalevy@...asas.com>,
	open-osd development <osd-dev@...n-osd.org>,
	Avishay Traeger <avishay@...il.com>,
	Jeff Garzik <jeff@...zik.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [osd-dev] [PATCH 1/9] exofs: osd Swiss army knife

Alan Cox wrote:
>>> +#define EXOFS_SUPER_ID	0x10000	/* object ID for on-disk superblock */
> 
> And if an OS failure breaks the super block and you have only one how do
> you recover it ?

There is nothing really in this object but the "next_id" which is recoverable
by an fsck utility (Not yet submitted) by a simple osd-list-partition
command. Same for num-of-files. All these values are just cached values,
for convenience.

> 
>>> +#define EXOFS_BM_ID	0x10001	/* object ID for ID bitmap */
Not used will be dropped

>>> +#define EXOFS_ROOT_ID	0x10002	/* object ID for root directory */
OK Only one, but so is all other directories. I'll think about it.
I'll probably postpone it for together with the raid management.

>>> +#define EXOFS_TEST_ID	0x10003	/* object ID for test object */
Not used will be dropped

> 
> Ditto some of the others
> 
>>> +	EXOFS_UINT64_MAX = (~0LL),
>>> +	EXOFS_MAX_INO_ID = (sizeof(ino_t) * 8 == 64) ? EXOFS_UINT64_MAX :
>>> +					(1LL << (sizeof(ino_t) * 8 - 1)),
> 
> Ok so thats quite a big number
> 
>>> +	uint32_t  s_nextid;	/* Highest object ID used */
I fixed all that to be __le64, you can see that on the web here:
http://git.open-osd.org/gitweb.cgi?p=open-osd.git;a=shortlog;h=refs/heads/exofs

I will submit another round ASAP. I'm currently busy with user-mode-library.
Once done I'll post the next exofs round. All these and lots of other areas where
converted to proper __leXX types. Specially the directory code had all these
missing. It was all triggered thanks to Morton who pointed me to all these ext2
bug-fixes since 2.6.10.

> 
> but that is a smaller one
> 
>>> +	uint32_t  s_numfiles;	/* Number of files on fs */
> 
> as is this

Yes also fixed to __le64

> 
>>> +	uint32_t  i_atime;        	/* Access time */
>>> +	uint32_t  i_ctime;        	/* Creation time */
>>> +	uint32_t  i_mtime;        	/* Modification time */
> 
> 2038 ? - bits are cheap
> 

OK Avisi got lazy, This is a copy form ext2. I will fix that,
thanks for pointing this out. I will put __le64 for seconds
and also add __le64 for nanoseconds while at it.

Thanks Ingo for your review
Boaz

--
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/