Theodore Ts'o wrote: ... > What are things that are still left to be done before we 64-bit support > is completely supported? Just a few things: > > * Currently the badblocks list mechanism only supports 32-bit blocks. > This may be OK, since running "badblocks" on a really large disk is > probably a fool's errand. But how we handle this is an open question; > should we just refuse "mke2fs -c" or "e2fsck -c" for really big file > systems? Should we deprecate the badblocks inode altogether? > > * The online resizing code, which relies on using a resize inode and > indirect blocks, will not scale to 64-bit filesystems. We have the > beginnings of support for the "meta_bg" style of resizing, which is > supported by the kernel and the e2fsprogs code --- but it hasn't been > implemented in the kernel yet. We need to add that. * Lazy inode table initialization so that large fs mkfs time is acceptable. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
