[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18731.57605.633119.670974@frecb006361.adech.frec.bull.fr>
Date: Tue, 25 Nov 2008 12:27:01 +0100
From: Solofo.Ramangalahy@...l.net
To: Andreas Dilger <adilger@....com>
Cc: Solofo.Ramangalahy@...l.net, linux-ext4@...r.kernel.org
Subject: Re: [RFC 1/2] ext4 resize: Mark the added group with
EXT4_BG_INODE_ZEROED flag
Andreas Dilger writes:
> > As a side note, online resize and inode zeroing are "dual".
> >
> > In order to obtain a filesystem with faster formating times one can
> > do:
> > . either format a smaller fs and then resize it,
> > . or format the fs with lazy_itable_init
>
> As discussed on the concall, it probably makes more sense to have the
> resize code work by marking the inode tables UNINIT (if GDT_CSUM feature
> is enabled)
If I understand correctly, this is already the case:
#define EXT4_BG_INODE_UNINIT 0x0001 /* Inode table/bitmap not in use */
#define EXT4_BG_BLOCK_UNINIT 0x0002 /* Block bitmap not in use */
#define EXT4_BG_INODE_ZEROED 0x0004 /* On-disk itable initialized to zero */
As the EXT4_BG_INODE_ZEROED is not present, the inode table is UNINIT.
By the way, is there any reason the #defines are like this, instead of:
#define EXT4_BG_INODE_UNINIT 0x0001 /* Inode table/bitmap not in use */
#define EXT4_BG_BLOCK_UNINIT 0x0002 /* Block bitmap not in use */
#define EXT4_BG_ITABLE_UNINIT 0x0004 /* On-disk itable not initialized */
?
> and then start the "itable zeroing" thread, if it isn't
> already running, to do the zeroing of the itable.
Yes.
Is there other resize changes you could think of?
While working on this, I noted this checkpatch error
"ERROR: do not use assignment in if condition"
(but I am not sure of the exact justification).
Thanks,
--
solofo
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists