On Aug 10, 2007 11:37 +0800, Coly Li wrote:
> - --- a/e2fsck/problem.h
> +++ b/e2fsck/problem.h
> @@ -558,8 +558,8 @@ struct problem_context {
> +/* Duplicate directory entry found */
> +#define PR_2_REPORT_DUP_DIRENT 0x02000D
>
> - -/* i_frag should be zero */
> - -#define PR_2_FRAG_ZERO 0x020010
> +/* Non-unique filename found */
> +#define PR_2_NON_UNIQUE_FILE 0x020010
>
> - -/* i_fsize should be zero */
> - -#define PR_2_FSIZE_ZERO 0x020011
> +/* i_blocks_hi should be zero */
> +#define PR_2_BLOCKS_HI_ZERO 0x020011
Please don't do this. This makes other patches fail to apply, and I don't
think we need to have sequential error numbers?
> struct {
> - - __u8 m_i_frag; /* Fragment number */
> - - __u8 m_i_fsize; /* Fragment size */
> - - __u16 m_pad1;
> - - __u32 m_i_reserved2[2];
> + __u32 m_i_reserved2[3];
It is a bad idea to declare on-disk fields "reserved[{num}]", because
if some code is ever using e.g. "reserved[0]" for something and then
one of the fields is "unreserved" then the other code will silently
continue to work, but it will be using some other field on disk...
That said, while we are removing junk you could also remove the "masix"
parts of the code, because I don't think they have been used for 10 years.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
