btrfs hangup when we run the "sync" command

BUG Miao Xie 4 participants 10 messages Jul 15, 2010 – Jul 21, 2010 Btrfs file system

lore

Share & tools

lore

Miao Xie

author

2010-07-15 03:18 UTC #0 lore raw

Hi, everyone

I found btrfs will hangup when we run the sync command on my x86_64 box.

The reproduce steps is following:

# mkfs.btrfs -s 8192 -l 8192 -n 8192 /dev/sda1
# mount /dev/sda1 /mnt
# echo 1234567 > /mnt/aaa
# sync
(btrfs hangs up)

It seems that the btrfs doesn't support the sectorsize which is greater than the page size just like ext2/3/4, though we can use mkfs.btrfs to make a filesystem with a big sectorsize. Am I right?

If yes, we must do more check in the mkfs.btrfs.

Thanks
Miao Xie

Yan, Zheng

2010-07-15 08:14 UTC #1 lore raw

2010/7/15 Miao Xie <[email protected]>:

Quoted 12 lines

Hi, everyone
I found btrfs will hangup when we run the sync command on my x86_64 box.
The reproduce steps is following:
# mkfs.btrfs -s 8192 -l 8192 -n 8192 /dev/sda1
# mount /dev/sda1 /mnt
# echo 1234567 > /mnt/aaa
# sync
(btrfs hangs up)

Quoted 6 lines

It seems that the btrfs doesn't support the sectorsize which is greater than the page size just like ext2/3/4, though we can use mkfs.btrfs to make a filesystem with a big sectorsize. Am I right?
If yes, we must do more check in the mkfs.btrfs.

yes, btrfs doesn't support the sectorsize > PAGE_size.

Miao Xie

author

2010-07-15 09:07 UTC #2 lore raw

Quoted 13 lines · Zheng

2010/7/15 Miao Xie<[email protected]>:
Quoted 12 lines
Hi, everyone
I found btrfs will hangup when we run the sync command on my x86_64 box.
The reproduce steps is following:
# mkfs.btrfs -s 8192 -l 8192 -n 8192 /dev/sda1
# mount /dev/sda1 /mnt
# echo 1234567>  /mnt/aaa
# sync
(btrfs hangs up)

Quoted 9 lines

Quoted 6 lines
It seems that the btrfs doesn't support the sectorsize which is greater than the page size just like ext2/3/4, though we can use mkfs.btrfs to make a filesystem with a big sectorsize. Am I right?
If yes, we must do more check in the mkfs.btrfs.
yes, btrfs doesn't support the sectorsize> PAGE_size.

So we must do more check in the mkfs.btrfs to avoid misuse, and I'll add some check of the sectorsize into the mkfs.btrfs.

BTW, I sent some patches to the btrfs community recently, but I haven't received any reply. Could you review them for me? though I have tested them and everything works well.

[PATCH 1/2] btrfs: restructure try_release_extent_buffer() [PATCH 2/2] btrfs: fix oops when leafsize is greator than nodesize [PATCH] btrfs-progs: fix wrong extent buffer size when reading tree block

Thanks
Miao Xie

Chris Mason

2010-07-15 16:12 UTC #3 lore raw

Quoted 18 lines · Miao Xie

Quoted 17 lines · Zheng
2010/7/15 Miao Xie<[email protected]>:
Quoted 16 lines
Hi, everyone
I found btrfs will hangup when we run the sync command on my x86_64 box.
The reproduce steps is following:
# mkfs.btrfs -s 8192 -l 8192 -n 8192 /dev/sda1
# mount /dev/sda1 /mnt
# echo 1234567>  /mnt/aaa
# sync
(btrfs hangs up)
It seems that the btrfs doesn't support the sectorsize which is greater than the page size just like ext2/3/4, though we can use mkfs.btrfs to make a filesystem with a big sectorsize. Am I right?

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
If yes, we must do more check in the mkfs.btrfs.
yes, btrfs doesn't support the sectorsize> PAGE_size.
So we must do more check in the mkfs.btrfs to avoid misuse, and I'll add some check of the sectorsize into the mkfs.btrfs.

Yes, but this is fixed up with the raid code, we'll allow different page sizes.

Quoted 8 lines

BTW, I sent some patches to the btrfs community recently, but I haven't received any reply. Could you review them for me? though I have tested them and everything works well.
[PATCH 1/2] btrfs: restructure try_release_extent_buffer() [PATCH 2/2] btrfs: fix oops when leafsize is greator than nodesize [PATCH] btrfs-progs: fix wrong extent buffer size when reading tree block

Thanks, I'll go through these.

-chris

Miao Xie

author

2010-07-19 01:56 UTC #4 lore raw

Quoted 7 lines · Chris Mason

Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
It seems that the btrfs doesn't support the sectorsize which is greater than the page size just like ext2/3/4, though we can use mkfs.btrfs to make a filesystem with a big sectorsize. Am I right?
If yes, we must do more check in the mkfs.btrfs.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
yes, btrfs doesn't support the sectorsize> PAGE_size.
So we must do more check in the mkfs.btrfs to avoid misuse, and I'll add some check of the sectorsize into the mkfs.btrfs.
Yes, but this is fixed up with the raid code, we'll allow different page sizes.

Is the raid code that you said the initialization code for the block devices? just like this:

fs/btrfs/volumes.c:1430
int btrfs_init_new_device(struct btrfs_root *root, char *device_path)

{
	[snip]
	set_blocksize(device->bdev, 4096);
	[snip]
}

If yes, it uses a hard-code value to initialize the blocksize of the block device, not the blocksize of the btrfs, so the btrfs doesn't check the blocksize of the btrfs.

Thanks
Miao Xie

Yan, Zheng

2010-07-19 02:01 UTC #5 lore raw

Quoted 22 lines · Miao Xie

Quoted 7 lines · Chris Mason
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
It seems that the btrfs doesn't support the sectorsize which is greater than the page size just like ext2/3/4, though we can use mkfs.btrfs to make a filesystem with a big sectorsize. Am I right?
If yes, we must do more check in the mkfs.btrfs.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
yes, btrfs doesn't support the sectorsize> PAGE_size.
So we must do more check in the mkfs.btrfs to avoid misuse, and I'll add some check of the sectorsize into the mkfs.btrfs.
Yes, but this is fixed up with the raid code, we'll allow different page sizes.
Is the raid code that you said the initialization code for the block devices? just like this:
fs/btrfs/volumes.c:1430
int btrfs_init_new_device(struct btrfs_root *root, char *device_path)

Quoted 9 lines

{
	[snip]
	set_blocksize(device->bdev, 4096);
	[snip]
}
If yes, it uses a hard-code value to initialize the blocksize of the block device, not the blocksize of the btrfs, so the btrfs doesn't check the blocksize of the btrfs.

This is for btrfs super block, because size of btrfs super block is fixed.

Yan, Zheng

Miao Xie

author

2010-07-19 06:17 UTC #6 lore raw

Quoted 29 lines · Zheng

Quoted 28 lines · Miao Xie
Quoted 7 lines · Chris Mason
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
It seems that the btrfs doesn't support the sectorsize which is greater than the page size just like ext2/3/4, though we can use mkfs.btrfs to make a filesystem with a big sectorsize. Am I right?
If yes, we must do more check in the mkfs.btrfs.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
yes, btrfs doesn't support the sectorsize> PAGE_size.
So we must do more check in the mkfs.btrfs to avoid misuse, and I'll add some check of the sectorsize into the mkfs.btrfs.
Yes, but this is fixed up with the raid code, we'll allow different page sizes.
Is the raid code that you said the initialization code for the block devices? just like this:
fs/btrfs/volumes.c:1430
int btrfs_init_new_device(struct btrfs_root *root, char *device_path)
{
	[snip]
	set_blocksize(device->bdev, 4096);
	[snip]
}

Quoted 4 lines

Quoted 3 lines
If yes, it uses a hard-code value to initialize the blocksize of the block device, not the blocksize of the btrfs, so the btrfs doesn't check the blocksize of the btrfs.
This is for btrfs super block, because size of btrfs super block is fixed.

I don't know how this bug was fixed up. I think if the btrfs doesn't support the >PAGE_SIZE sectorsize, it should forbid mounting a filesystem with >PAGE_SIZE sectorsize. But in fact, we can mount.

So I think this bug has not been fixed up or the fix is not so good.

Thanks
Miao Xie

Yan, Zheng

2010-07-19 06:46 UTC #7 lore raw

Quoted 1 line · Miao Xie

On Mon, 19 Jul 2010 10:01:26 +0800, Yan, Zheng <[email protected]>=

Quoted 2 lines · wrote:

Quoted 2 lines · Miao Xie
Quoted 1 line
On Thu, 15 Jul 2010 12:12:13 -0400, Chris Mason <chris.mason@oracle=

Quoted 2 lines · =2Ecom> wrote:

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
It seems that the btrfs doesn't support the sectorsize which is greater than the page size just like ext2/3/4, though we can us=

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
mkfs.btrfs to make a filesystem with a big sectorsize. Am I rig=

ht?

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
If yes, we must do more check in the mkfs.btrfs.
yes, btrfs doesn't support the sectorsize> =A0PAGE_size.
So we must do more check in the mkfs.btrfs to avoid misuse, and I=

'll

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
add some check of the sectorsize into the mkfs.btrfs.
Yes, but this is fixed up with the raid code, we'll allow differen=

t page

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 1 line
sizes.
Is the raid code that you said the initialization code for the bloc=

k devices?

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
just like this:
fs/btrfs/volumes.c:1430
int btrfs_init_new_device(struct btrfs_root *root, char *device_pat=

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
{
=A0 =A0 =A0[snip]
=A0 =A0 =A0set_blocksize(device->bdev, 4096);
=A0 =A0 =A0[snip]
}
If yes, it uses a hard-code value to initialize the blocksize of th=

e block device,

Quoted 1 line

Quoted 1 line
Quoted 1 line
not the blocksize of the btrfs, so the btrfs doesn't check the bloc=

ksize of the btrfs.

Quoted 2 lines

Quoted 2 lines
Quoted 1 line
This is for btrfs super block, because size of btrfs super block is =

fixed.

Quoted 2 lines

I don't know how this bug was fixed up. I think if the btrfs doesn't =

support

Quoted 1 line

the >PAGE_SIZE sectorsize, it should forbid mounting a filesystem wit=

h >PAGE_SIZE

Quoted 4 lines

sectorsize. But in fact, we can mount.
So I think this bug has not been fixed up or the fix is not so good.

This bug has been fixed up in Chris' raid56 tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Miao Xie

author

2010-07-19 08:29 UTC #8 lore raw

Quoted 22 lines · Zheng

Quoted 22 lines
Quoted 21 lines
Quoted 11 lines
Quoted 5 lines
Quoted 2 lines
So we must do more check in the mkfs.btrfs to avoid misuse, and I'll add some check of the sectorsize into the mkfs.btrfs.
Yes, but this is fixed up with the raid code, we'll allow different page sizes.
Is the raid code that you said the initialization code for the block devices? just like this:
fs/btrfs/volumes.c:1430
int btrfs_init_new_device(struct btrfs_root *root, char *device_path)
Quoted 9 lines
{
      [snip]
      set_blocksize(device->bdev, 4096);
      [snip]
}
If yes, it uses a hard-code value to initialize the blocksize of the block device, not the blocksize of the btrfs, so the btrfs doesn't check the blocksize of the btrfs.
This is for btrfs super block, because size of btrfs super block is fixed.

Quoted 8 lines

Quoted 6 lines
I don't know how this bug was fixed up. I think if the btrfs doesn't support the>PAGE_SIZE sectorsize, it should forbid mounting a filesystem with>PAGE_SIZE sectorsize. But in fact, we can mount.
So I think this bug has not been fixed up or the fix is not so good.
This bug has been fixed up in Chris' raid56 tree.

I see, thanks!

BTW: could you tell us the URL of Chris' raid56 tree? I just find the raid56 tree
that is managed by David Woodhouse.
http://git.infradead.org/users/dwmw2/btrfs-raid56.git

Regards
Miao Xie

Hubert Kario

2010-07-21 12:36 UTC #9 lore raw

In reply to Miao Xie

Quoted 19 lines · On Thursday 15 July 2010 11:07:07 Miao Xie wrote:

Quoted 18 lines · Zheng
2010/7/15 Miao Xie<[email protected]>:
Quoted 17 lines
Hi, everyone
=20
I found btrfs will hangup when we run the sync command on my x86_64 box.
=20
The reproduce steps is following:
# mkfs.btrfs -s 8192 -l 8192 -n 8192 /dev/sda1
# mount /dev/sda1 /mnt
# echo 1234567>  /mnt/aaa
# sync
(btrfs hangs up)
=20
It seems that the btrfs doesn't support the sectorsize which is
greater than the page size just like ext2/3/4, though we can use
mkfs.btrfs to make a filesystem with a big sectorsize. Am I right?
=20
If yes, we must do more check in the mkfs.btrfs.

Quoted 5 lines

Quoted 2 lines
=20
yes, btrfs doesn't support the sectorsize> PAGE_size.
=20
So we must do more check in the mkfs.btrfs to avoid misuse, and I'll add some check of the sectorsize into the mkfs.btrfs.

I don't think that denying of creation of FSs with sectorsize > pagesiz= e is a=20
good idea. A warning would be better:

Warning: The filesystem you are about to create won't be usable on your= =20
computer architecture. Do you want to continue? y/n:

Unless the FS created in such way is unusabe in any circumstances...

Quoted 1 line

BTW, I sent some patches to the btrfs community recently, but I haven=

Quoted 1 line

received any reply. Could you review them for me? though I have teste=

Quoted 5 lines

them and everything works well.
=20
[PATCH 1/2] btrfs: restructure try_release_extent_buffer() [PATCH 2/2] btrfs: fix oops when leafsize is greator than nodesize [PATCH] btrfs-progs: fix wrong extent buffer size when reading tree b=

lock

Quoted 3 lines

=20
Thanks
Miao Xie

--=20
Hubert Kario
QBS - Quality Business Software
ul. Ksawer=F3w 30/85
02-656 Warszawa
POLAND
tel. +48 (22) 646-61-51, 646-74-24
fax +48 (22) 646-61-50
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html