Before we go whole-hog on 64-bit e2fsprogs, I wonder if this
is worth considering as a last-minute addition to the 1.41
stream. Currently, mke2fs will shave a block off an exactly-16T
device to fit*, but resize2fs does not do the same, leading
to some asymmetry. This patch fixes that up, and allows 16T
devices to be handled more gracefully in offline resize.
(in fact resize2fs will not even open a 16T device, today).
*commit 37d17a65ecb4615546b417038190a41bafca7c51
Signed-off-by: Eric Sandeen <[email protected]>
---
Index: e2fsprogs-1.41.12/resize/main.c
===================================================================
--- e2fsprogs-1.41.12.orig/resize/main.c
+++ e2fsprogs-1.41.12/resize/main.c
@@ -159,7 +159,7 @@ int main (int argc, char ** argv)
int print_min_size = 0;
int fd, ret;
blk_t new_size = 0;
- blk_t max_size = 0;
+ blk64_t max_size = 0;
blk_t min_size = 0;
io_manager io_ptr;
char *new_size_str = 0;
@@ -375,7 +375,7 @@ int main (int argc, char ** argv)
* defaults and for making sure the new filesystem doesn't
* exceed the partition size.
*/
- retval = ext2fs_get_device_size(device_name, fs->blocksize,
+ retval = ext2fs_get_device_size2(device_name, fs->blocksize,
&max_size);
if (retval) {
com_err(program_name, retval,
@@ -393,6 +393,14 @@ int main (int argc, char ** argv)
exit(1);
}
} else {
+ /* Take down devices exactly 16T to 2^32-1 blocks */
+ if (max_size == (1ULL << 32))
+ max_size--;
+ else if (max_size > (1ULL << 32)) {
+ com_err(program_name, 0, _("New size too large to be "
+ "expressed in 32 bits\n"));
+ exit(1);
+ }
new_size = max_size;
/* Round down to an even multiple of a pagesize */
if (sys_page_size > fs->blocksize)
@@ -432,7 +441,7 @@ int main (int argc, char ** argv)
}
if (!force && (new_size > max_size)) {
fprintf(stderr, _("The containing partition (or device)"
- " is only %u (%dk) blocks.\nYou requested a new size"
+ " is only %llu (%dk) blocks.\nYou requested a new size"
" of %u blocks.\n\n"), max_size,
fs->blocksize / 1024, new_size);
exit(1);
On Wed, 15 Dec 2010, Eric Sandeen wrote:
> Before we go whole-hog on 64-bit e2fsprogs, I wonder if this
> is worth considering as a last-minute addition to the 1.41
> stream. Currently, mke2fs will shave a block off an exactly-16T
> device to fit*, but resize2fs does not do the same, leading
> to some asymmetry. This patch fixes that up, and allows 16T
> devices to be handled more gracefully in offline resize.
> (in fact resize2fs will not even open a 16T device, today).
>
> *commit 37d17a65ecb4615546b417038190a41bafca7c51
>
> Signed-off-by: Eric Sandeen <[email protected]>
Hi Eric,
which version of e2fsprogs are you referring to ? When I look at master
branch I can see than those changes are already in there. Except the check
if the new size is too large. Am I missing something ?
-Lukas
> ---
>
> Index: e2fsprogs-1.41.12/resize/main.c
> ===================================================================
> --- e2fsprogs-1.41.12.orig/resize/main.c
> +++ e2fsprogs-1.41.12/resize/main.c
> @@ -159,7 +159,7 @@ int main (int argc, char ** argv)
> int print_min_size = 0;
> int fd, ret;
> blk_t new_size = 0;
> - blk_t max_size = 0;
> + blk64_t max_size = 0;
> blk_t min_size = 0;
> io_manager io_ptr;
> char *new_size_str = 0;
> @@ -375,7 +375,7 @@ int main (int argc, char ** argv)
> * defaults and for making sure the new filesystem doesn't
> * exceed the partition size.
> */
> - retval = ext2fs_get_device_size(device_name, fs->blocksize,
> + retval = ext2fs_get_device_size2(device_name, fs->blocksize,
> &max_size);
> if (retval) {
> com_err(program_name, retval,
> @@ -393,6 +393,14 @@ int main (int argc, char ** argv)
> exit(1);
> }
> } else {
> + /* Take down devices exactly 16T to 2^32-1 blocks */
> + if (max_size == (1ULL << 32))
> + max_size--;
> + else if (max_size > (1ULL << 32)) {
> + com_err(program_name, 0, _("New size too large to be "
> + "expressed in 32 bits\n"));
> + exit(1);
> + }
> new_size = max_size;
> /* Round down to an even multiple of a pagesize */
> if (sys_page_size > fs->blocksize)
> @@ -432,7 +441,7 @@ int main (int argc, char ** argv)
> }
> if (!force && (new_size > max_size)) {
> fprintf(stderr, _("The containing partition (or device)"
> - " is only %u (%dk) blocks.\nYou requested a new size"
> + " is only %llu (%dk) blocks.\nYou requested a new size"
> " of %u blocks.\n\n"), max_size,
> fs->blocksize / 1024, new_size);
> exit(1);
> --
> 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
>
--
On 12/16/10 3:00 AM, Lukas Czerner wrote:
> On Wed, 15 Dec 2010, Eric Sandeen wrote:
>
>> Before we go whole-hog on 64-bit e2fsprogs, I wonder if this
>> is worth considering as a last-minute addition to the 1.41
>> stream. Currently, mke2fs will shave a block off an exactly-16T
>> device to fit*, but resize2fs does not do the same, leading
>> to some asymmetry. This patch fixes that up, and allows 16T
>> devices to be handled more gracefully in offline resize.
>> (in fact resize2fs will not even open a 16T device, today).
>>
>> *commit 37d17a65ecb4615546b417038190a41bafca7c51
>>
>> Signed-off-by: Eric Sandeen <[email protected]>
>
> Hi Eric,
>
> which version of e2fsprogs are you referring to ? When I look at master
> branch I can see than those changes are already in there. Except the check
> if the new size is too large. Am I missing something ?
Hm I may have gotten lost in branches. I was looking at 1.41.12...
I didn't think 64-bit work had been merged there yet.
I'm not sure what ted is basing 1.41.XX off of...
-Eric
> -Lukas
>
>> ---
>>
>> Index: e2fsprogs-1.41.12/resize/main.c
>> ===================================================================
>> --- e2fsprogs-1.41.12.orig/resize/main.c
>> +++ e2fsprogs-1.41.12/resize/main.c
>> @@ -159,7 +159,7 @@ int main (int argc, char ** argv)
>> int print_min_size = 0;
>> int fd, ret;
>> blk_t new_size = 0;
>> - blk_t max_size = 0;
>> + blk64_t max_size = 0;
>> blk_t min_size = 0;
>> io_manager io_ptr;
>> char *new_size_str = 0;
>> @@ -375,7 +375,7 @@ int main (int argc, char ** argv)
>> * defaults and for making sure the new filesystem doesn't
>> * exceed the partition size.
>> */
>> - retval = ext2fs_get_device_size(device_name, fs->blocksize,
>> + retval = ext2fs_get_device_size2(device_name, fs->blocksize,
>> &max_size);
>> if (retval) {
>> com_err(program_name, retval,
>> @@ -393,6 +393,14 @@ int main (int argc, char ** argv)
>> exit(1);
>> }
>> } else {
>> + /* Take down devices exactly 16T to 2^32-1 blocks */
>> + if (max_size == (1ULL << 32))
>> + max_size--;
>> + else if (max_size > (1ULL << 32)) {
>> + com_err(program_name, 0, _("New size too large to be "
>> + "expressed in 32 bits\n"));
>> + exit(1);
>> + }
>> new_size = max_size;
>> /* Round down to an even multiple of a pagesize */
>> if (sys_page_size > fs->blocksize)
>> @@ -432,7 +441,7 @@ int main (int argc, char ** argv)
>> }
>> if (!force && (new_size > max_size)) {
>> fprintf(stderr, _("The containing partition (or device)"
>> - " is only %u (%dk) blocks.\nYou requested a new size"
>> + " is only %llu (%dk) blocks.\nYou requested a new size"
>> " of %u blocks.\n\n"), max_size,
>> fs->blocksize / 1024, new_size);
>> exit(1);
>> --
>> 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
>>
>
On Thu, Dec 16, 2010 at 10:00:26AM +0100, Lukas Czerner wrote:
>
> which version of e2fsprogs are you referring to ? When I look at master
> branch I can see than those changes are already in there. Except the check
> if the new size is too large. Am I missing something ?
The 1.41.x series is on the "maint" branch.
The 1.42 version is on the main "master" and "next" branch, where
"next" is where I'll check in things initially, and then "master"
catches up with "next". I took this from git, with the basic idea
being that if there are people who are testing next, and people who
are using the "master", hopefully problems get noticed and fixed
before people are using "master" grab a commit. To be honest there
probably aren't enough people tracking next and master for this to
make a huge amount of difference, but I'm following this scheme
anyway.
- Ted
On Wed, Dec 15, 2010 at 10:37:34PM -0600, Eric Sandeen wrote:
> Before we go whole-hog on 64-bit e2fsprogs, I wonder if this
> is worth considering as a last-minute addition to the 1.41
> stream. Currently, mke2fs will shave a block off an exactly-16T
> device to fit*, but resize2fs does not do the same, leading
> to some asymmetry. This patch fixes that up, and allows 16T
> devices to be handled more gracefully in offline resize.
> (in fact resize2fs will not even open a 16T device, today).
>
> *commit 37d17a65ecb4615546b417038190a41bafca7c51
>
> Signed-off-by: Eric Sandeen <[email protected]>
Thanks, added to the maint branch.
- Ted
"Ted Ts'o" <[email protected]> writes:
> The 1.42 version is on the main "master" and "next" branch, where
> "next" is where I'll check in things initially, and then "master"
> catches up with "next". I took this from git, with the basic idea
> being that if there are people who are testing next, and people who
> are using the "master", hopefully problems get noticed and fixed
> before people are using "master" grab a commit. To be honest there
> probably aren't enough people tracking next and master for this to
> make a huge amount of difference, but I'm following this scheme
> anyway.
So, I am doing the right thing, when I use the master branch for my 20TB
filesystem? Or shall I try next, at least until I decide to actually use
the filesystem for something real?
--
Stephan