* [PATCH] resize2fs: handle exactly-16T filesystems in resize2fs
@ 2010-12-16 4:37 Eric Sandeen
2010-12-16 9:00 ` Lukas Czerner
2010-12-17 0:18 ` Ted Ts'o
0 siblings, 2 replies; 6+ messages in thread
From: Eric Sandeen @ 2010-12-16 4:37 UTC (permalink / raw)
To: Theodore Tso, ext4 development
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 <sandeen@redhat.com>
---
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);
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] resize2fs: handle exactly-16T filesystems in resize2fs
2010-12-16 4:37 [PATCH] resize2fs: handle exactly-16T filesystems in resize2fs Eric Sandeen
@ 2010-12-16 9:00 ` Lukas Czerner
2010-12-16 14:57 ` Eric Sandeen
2010-12-17 0:15 ` Ted Ts'o
2010-12-17 0:18 ` Ted Ts'o
1 sibling, 2 replies; 6+ messages in thread
From: Lukas Czerner @ 2010-12-16 9:00 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Theodore Tso, ext4 development
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 <sandeen@redhat.com>
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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] resize2fs: handle exactly-16T filesystems in resize2fs
2010-12-16 9:00 ` Lukas Czerner
@ 2010-12-16 14:57 ` Eric Sandeen
2010-12-17 0:15 ` Ted Ts'o
1 sibling, 0 replies; 6+ messages in thread
From: Eric Sandeen @ 2010-12-16 14:57 UTC (permalink / raw)
To: Lukas Czerner; +Cc: Theodore Tso, ext4 development
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 <sandeen@redhat.com>
>
> 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 majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] resize2fs: handle exactly-16T filesystems in resize2fs
2010-12-16 9:00 ` Lukas Czerner
2010-12-16 14:57 ` Eric Sandeen
@ 2010-12-17 0:15 ` Ted Ts'o
2010-12-17 8:06 ` Stephan Boettcher
1 sibling, 1 reply; 6+ messages in thread
From: Ted Ts'o @ 2010-12-17 0:15 UTC (permalink / raw)
To: Lukas Czerner; +Cc: Eric Sandeen, ext4 development
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] resize2fs: handle exactly-16T filesystems in resize2fs
2010-12-16 4:37 [PATCH] resize2fs: handle exactly-16T filesystems in resize2fs Eric Sandeen
2010-12-16 9:00 ` Lukas Czerner
@ 2010-12-17 0:18 ` Ted Ts'o
1 sibling, 0 replies; 6+ messages in thread
From: Ted Ts'o @ 2010-12-17 0:18 UTC (permalink / raw)
To: Eric Sandeen; +Cc: ext4 development
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 <sandeen@redhat.com>
Thanks, added to the maint branch.
- Ted
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] resize2fs: handle exactly-16T filesystems in resize2fs
2010-12-17 0:15 ` Ted Ts'o
@ 2010-12-17 8:06 ` Stephan Boettcher
0 siblings, 0 replies; 6+ messages in thread
From: Stephan Boettcher @ 2010-12-17 8:06 UTC (permalink / raw)
To: Ted Ts'o; +Cc: ext4 development
"Ted Ts'o" <tytso@mit.edu> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-12-17 8:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-16 4:37 [PATCH] resize2fs: handle exactly-16T filesystems in resize2fs Eric Sandeen
2010-12-16 9:00 ` Lukas Czerner
2010-12-16 14:57 ` Eric Sandeen
2010-12-17 0:15 ` Ted Ts'o
2010-12-17 8:06 ` Stephan Boettcher
2010-12-17 0:18 ` Ted Ts'o
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).