| Message ID | CAGW2f1Fn2caBtQPjZnXyMdVf9H6wGvS_0YrLReggwujKZXL8CQ@mail.gmail.com |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Thu, Apr 10, 2014 at 12:13:49AM -0400, jon ernst wrote: > > Because bigalloc requires cluster-aware bitfield operations, which > means we need EXT2_FLAG_64BITS. > I see e2image.c creates image always with EXT2_FLAG_64BITS flag. It is > safe to do same thing for e4defrag in my opinion. Please correct me if > I am wrong. Um.... I *think* so. e4defrag is one of the less well tested/maintained parts of e2fsprogs, as well as the kernel-side code which supports e4defrag. I can't think of any reason why there would be any 32-bit dependencies in the kernel side code, although someone should probably do a quick audit of the e4defrag code to make sure it's not using blk_t where it should be using blk64_t, or have other 32-bit dependencies. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 10, 2014 at 09:56:37AM -0400, Theodore Ts'o wrote: > On Thu, Apr 10, 2014 at 12:13:49AM -0400, jon ernst wrote: > > > > Because bigalloc requires cluster-aware bitfield operations, which > > means we need EXT2_FLAG_64BITS. > > I see e2image.c creates image always with EXT2_FLAG_64BITS flag. It is > > safe to do same thing for e4defrag in my opinion. Please correct me if > > I am wrong. > > Um.... I *think* so. e4defrag is one of the less well > tested/maintained parts of e2fsprogs, as well as the kernel-side code > which supports e4defrag. I can't think of any reason why there would > be any 32-bit dependencies in the kernel side code, although someone > should probably do a quick audit of the e4defrag code to make sure > it's not using blk_t where it should be using blk64_t, or have other > 32-bit dependencies. From a quick visual inspection and a sparse bitwise check, e4defrag looks 64bit clean. --D > > - Ted > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 10, 2014 at 11:42:15AM -0700, Darrick J. Wong wrote: > > From a quick visual inspection and a sparse bitwise check, e4defrag looks 64bit > clean. Thanks for checking! I've applied Jon's patch. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 10, 2014 at 11:07 PM, Theodore Ts'o <tytso@mit.edu> wrote: > On Thu, Apr 10, 2014 at 11:42:15AM -0700, Darrick J. Wong wrote: >> >> From a quick visual inspection and a sparse bitwise check, e4defrag looks 64bit >> clean. > > Thanks for checking! I've applied Jon's patch. > > - Ted Thanks Ted, I have also checked e4defrag.c with eyeballs. All physical blocks are represented by 64bit. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/misc/e4defrag.c b/misc/e4defrag.c index 620f4e7..c5a2754 100644 --- a/misc/e4defrag.c +++ b/misc/e4defrag.c @@ -1794,7 +1794,7 @@ int main(int argc, char *argv[]) if (current_uid == ROOT_UID) { /* Get super block info */ - ret = ext2fs_open(dev_name, 0, 0, block_size, + ret = ext2fs_open(dev_name,EXT2_FLAG_64BITS, 0, block_size, unix_io_manager, &fs); if (ret) {