New experimental btrfs branch ready for testing

Hello everyone,

Yan Zheng has been doing some major surgery to the back references and extent allocation code, tackling bottlenecks in the code that tracks extents. It scales better with many snapshots and performs better in the common case of no snapshots at all.

THE NEW CODE IS A FORWARD ROLLING DISK FORMAT CHANGE. This means it is compatible with the current btrfs disk format, but once you mount a filesystem with the new code, it WILL NO LONGER BE MOUNTABLE FROM OLD KERNELS. Old kernels spit out an error message when you try them on new format filesystems.

Quoted 7 lines · Chris Mason

Hello everyone,

Yan Zheng has been doing some major surgery to the back references and extent allocation code, tackling bottlenecks in the code that tracks extents. It scales better with many snapshots and performs better in the common case of no snapshots at all.

Quoted 5 lines

THE NEW CODE IS A FORWARD ROLLING DISK FORMAT CHANGE. This means it is compatible with the current btrfs disk format, but once you mount a filesystem with the new code, it WILL NO LONGER BE MOUNTABLE FROM OLD KERNELS. Old kernels spit out an error message when you try them on new format filesystems.

Just a quick note that I'm having some issues with the backward compatibility code on 32 bit kernels. It can still read all the old items but it is having problems with creating new backrefs.

32bit is working fine on an entirely new format FS, and my 64 bit box can read and write the old format FS just fine. I'm hoping to track this one down today, but it would be a good idea to wait if you want to try the new code on old filesystems on 32 bit machines.

If you do hit crashes, please don't immediately reformat your FS if you can avoid it. We should be able to fix most problems people hit.

Hello everyone,

Yan Zheng has been doing some major surgery to the back references and extent allocation code, tackling bottlenecks in the code that tracks extents. It scales better with many snapshots and performs better in the common case of no snapshots at all.

THE NEW CODE IS A FORWARD ROLLING DISK FORMAT CHANGE. This means it is compatible with the current btrfs disk format, but once you mount a filesystem with the new code, it WILL NO LONGER BE MOUNTABLE FROM OLD KERNELS. Old kernels spit out an error message when you try them on new format filesystems.

This is a large change, and I'm hoping to have it stable in time for the 2.6.31 merge window. I've been testing it for about a week now, and haven't been able to cause major problems yet. But, testing the compatibility with old format filesystems is the hard part, and everyone that pulls the new code should backup their data first.

I've setup git branches called newformat where you can pull the new code.

For the kernel (based on 2.6.30-rc7):

git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git newformat

For the progs:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git newformat

The main benefit of the new code is that backrefs on the extent allocation tree use a fuzzier format. It basically means that we search for the key in the extent allocation tree instead of providing an exact backref to the parent block.

This means we can predict how many blocks will be changed when changing the extent allocation tree, and it makes enospc much less complex. It is also significantly faster.

For regular subvolume trees, a similar change is made as long as there are no snapshots against a given block. This is the common case, and it makes COW less expensive overall.

Yan Zheng also worked out a way to free blocks during the transaction without needing to do an explicit snapshot deletion on the old root when the transaction was done. This gets rid of some complex caching code, and fixes worst-case problems where btrfs could take a very very long time to unmount.

btrfs-vol -b is faster with the new code as well, he added caching of high levels in the tree to speed things up.

(Many kudos to Yan Zheng for all of this work!)

-chris

--
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

Quoted 23 lines · Chris Mason

Hello everyone,

Yan Zheng has been doing some major surgery to the back references and extent allocation code, tackling bottlenecks in the code that tracks extents. It scales better with many snapshots and performs better in the common case of no snapshots at all.

THE NEW CODE IS A FORWARD ROLLING DISK FORMAT CHANGE. This means it is compatible with the current btrfs disk format, but once you mount a filesystem with the new code, it WILL NO LONGER BE MOUNTABLE FROM OLD KERNELS. Old kernels spit out an error message when you try them on new format filesystems.

This is a large change, and I'm hoping to have it stable in time for the 2.6.31 merge window. I've been testing it for about a week now, and haven't been able to cause major problems yet. But, testing the compatibility with old format filesystems is the hard part, and everyone that pulls the new code should backup their data first.

I've setup git branches called newformat where you can pull the new code.

For the kernel (based on 2.6.30-rc7):

Quoted 3 lines

git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git newformat

So I started the performance runs on this. The base tests completed fine on the raid system and I will post results as soon as I can finish postprocessing, but when I tried to do nodatacow that machine it crashed pretty early. Here is console log:

Quoted 23 lines · Chris Mason

Hello everyone,

Yan Zheng has been doing some major surgery to the back references and extent allocation code, tackling bottlenecks in the code that tracks extents. It scales better with many snapshots and performs better in the common case of no snapshots at all.

THE NEW CODE IS A FORWARD ROLLING DISK FORMAT CHANGE. This means it is compatible with the current btrfs disk format, but once you mount a filesystem with the new code, it WILL NO LONGER BE MOUNTABLE FROM OLD KERNELS. Old kernels spit out an error message when you try them on new format filesystems.

This is a large change, and I'm hoping to have it stable in time for the 2.6.31 merge window. I've been testing it for about a week now, and haven't been able to cause major problems yet. But, testing the compatibility with old format filesystems is the hard part, and everyone that pulls the new code should backup their data first.

I've setup git branches called newformat where you can pull the new code.

For the kernel (based on 2.6.30-rc7):

Quoted 3 lines

git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git newformat

So I started the performance runs on this. The base tests completed fine on the raid system and I will post results as soon as I can finish postprocessing, but when I tried to do nodatacow that machine it crashed pretty early. Here is console log:

Quoted 29 lines · Steven Pratt

Quoted 27 lines · Chris Mason

Hello everyone,

Yan Zheng has been doing some major surgery to the back references and extent allocation code, tackling bottlenecks in the code that tracks extents. It scales better with many snapshots and performs better in the common case of no snapshots at all.

THE NEW CODE IS A FORWARD ROLLING DISK FORMAT CHANGE. This means it is compatible with the current btrfs disk format, but once you mount a filesystem with the new code, it WILL NO LONGER BE MOUNTABLE FROM OLD KERNELS. Old kernels spit out an error message when you try them on new format filesystems.

This is a large change, and I'm hoping to have it stable in time for the 2.6.31 merge window. I've been testing it for about a week now, and haven't been able to cause major problems yet. But, testing the compatibility with old format filesystems is the hard part, and everyone that pulls the new code should backup their data first.

I've setup git branches called newformat where you can pull the new code.

For the kernel (based on 2.6.30-rc7):

git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git newformat

Quoted 2 lines

So I started the performance runs on this. The base tests completed fine on the raid system and I will post results as soon as I can finish postprocessing, but when I tried to do nodatacow that machine it crashed pretty early. Here is console log:

Hi Steve,

Thanks again for hammering on these. Yan Zheng and I have both been trying to reproduce problems with nodatacow and with the database random write run.

But, so far we haven't been able to trigger any crashes. Do you see
anything in your config or setup that is unusual?

-chris

Quoted 30 lines · Chris Mason

Quoted 28 lines · Steven Pratt

Quoted 26 lines · Chris Mason

Hello everyone,

Yan Zheng has been doing some major surgery to the back references and extent allocation code, tackling bottlenecks in the code that tracks extents. It scales better with many snapshots and performs better in the common case of no snapshots at all.

THE NEW CODE IS A FORWARD ROLLING DISK FORMAT CHANGE. This means it is compatible with the current btrfs disk format, but once you mount a filesystem with the new code, it WILL NO LONGER BE MOUNTABLE FROM OLD KERNELS. Old kernels spit out an error message when you try them on new format filesystems.

This is a large change, and I'm hoping to have it stable in time for the 2.6.31 merge window. I've been testing it for about a week now, and haven't been able to cause major problems yet. But, testing the compatibility with old format filesystems is the hard part, and everyone that pulls the new code should backup their data first.

I've setup git branches called newformat where you can pull the new code.

For the kernel (based on 2.6.30-rc7):

git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git newformat

Quoted 9 lines

Quoted 2 lines

So I started the performance runs on this. The base tests completed fine on the raid system and I will post results as soon as I can finish postprocessing, but when I tried to do nodatacow that machine it crashed pretty early. Here is console log:

Hi Steve,

Thanks again for hammering on these. Yan Zheng and I have both been trying to reproduce problems with nodatacow and with the database random write run.

So now that the raid machine is actually up, I discovered it got further than I thought on nodatacow. It did all the read tests, but appeared to died on 16 thread random write(not odirect). There were no messages logged to var/log/messages at all. Last I saw was :

Jun  4 03:14:24 btrfs1 kernel: [65856.065491] btrfs: setting nodatacow
Jun  4 15:24:45 btrfs1 syslogd 1.4.1: restart.

Just dead until we rebooted machine later that day.

Quoted 4 lines

But, so far we haven't been able to trigger any crashes. Do you see
anything in your config or setup that is unusual?

No, other than using the old mkfs with the new format. I've kicked off new runs to see if I hit the same issues

Steve

Quoted 2 lines

-chris

Signature · 3 lines

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

Quoted 54 lines · Steven Pratt

Quoted 42 lines · Chris Mason

Quoted 34 lines · Steven Pratt

Quoted 22 lines · Chris Mason

Hello everyone,

Yan Zheng has been doing some major surgery to the back references and extent allocation code, tackling bottlenecks in the code that tracks extents. It scales better with many snapshots and performs better in the common case of no snapshots at all.

THE NEW CODE IS A FORWARD ROLLING DISK FORMAT CHANGE. This means it is
compatible with the current btrfs disk format, but once you mount a filesystem with the new code, it WILL NO LONGER BE MOUNTABLE FROM OLD KERNELS. Old kernels spit out an error message when you try them on new
format filesystems.

This is a large change, and I'm hoping to have it stable in time for the
2.6.31 merge window. I've been testing it for about a week now, and haven't been able to cause major problems yet. But, testing the compatibility with old format filesystems is the hard part, and everyone that pulls the new code should backup their data first.

Quoted 10 lines

I've setup git branches called newformat where you can pull the new code.

For the kernel (based on 2.6.30-rc7):

git pull
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git
newformat

Quoted 5 lines

So I started the performance runs on this. The base tests completed fine on the raid system and I will post results as soon as I can finish postprocessing, but when I tried to do nodatacow that machine it crashed pretty early. Here is console log:

Quoted 6 lines

Hi Steve,

Thanks again for hammering on these. Yan Zheng and I have both been trying to reproduce problems with nodatacow and with the database random write run.

So now that the raid machine is actually up, I discovered it got further than I thought on nodatacow. It did all the read tests, but appeared to died on 16 thread random write(not odirect). There were no messages logged to var/log/messages at all. Last I saw was :

Quoted 4 lines

Jun  4 03:14:24 btrfs1 kernel: [65856.065491] btrfs: setting nodatacow
Jun  4 15:24:45 btrfs1 syslogd 1.4.1: restart.

Just dead until we rebooted machine later that day.

So the raid system complete the re-run of the nodatacow runs without error. So still no idea what happened on this box the first time around. As for the single disk system, it died during the random write test again, but it now looks like we might have a real HW failure. This time we see SCSI error messages. I have replaced the test disks and will try one more time.

The net is, I would hold off digging too much into this as even I don't have any repeatable errors.

Quoted 52 lines · Steven Pratt

Quoted 50 lines · Steven Pratt

Quoted 33 lines · Chris Mason

Quoted 30 lines · Steven Pratt

Quoted 27 lines · Chris Mason

Hello everyone,

Yan Zheng has been doing some major surgery to the back references and extent allocation code, tackling bottlenecks in the code that tracks extents. It scales better with many snapshots and performs better in the common case of no snapshots at all.

THE NEW CODE IS A FORWARD ROLLING DISK FORMAT CHANGE. This means it is compatible with the current btrfs disk format, but once you mount a filesystem with the new code, it WILL NO LONGER BE MOUNTABLE FROM OLD KERNELS. Old kernels spit out an error message when you try them on new format filesystems.

This is a large change, and I'm hoping to have it stable in time for the 2.6.31 merge window. I've been testing it for about a week now, and haven't been able to cause major problems yet. But, testing the compatibility with old format filesystems is the hard part, and everyone that pulls the new code should backup their data first.

I've setup git branches called newformat where you can pull the new code.

For the kernel (based on 2.6.30-rc7):

git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git newformat

Quoted 10 lines

Quoted 3 lines

So I started the performance runs on this. The base tests completed fine on the raid system and I will post results as soon as I can finish postprocessing, but when I tried to do nodatacow that machine it crashed pretty early. Here is console log:

Hi Steve,

Thanks again for hammering on these. Yan Zheng and I have both been trying to reproduce problems with nodatacow and with the database random write run.

So now that the raid machine is actually up, I discovered it got further than I thought on nodatacow. It did all the read tests, but appeared to died on 16 thread random write(not odirect). There were no messages logged to var/log/messages at all. Last I saw was :

Jun  4 03:14:24 btrfs1 kernel: [65856.065491] btrfs: setting nodatacow
Jun  4 15:24:45 btrfs1 syslogd 1.4.1: restart.

Quoted 6 lines

Quoted 2 lines

Just dead until we rebooted machine later that day.

So the raid system complete the re-run of the nodatacow runs without error. So still no idea what happened on this box the first time around. As for the single disk system, it died during the random write test again, but it now looks like we might have a real HW failure. This time we see SCSI error messages. I have replaced the test disks and will try one more time.

The net is, I would hold off digging too much into this as even I don't have any repeatable errors.

Thanks for rerunning all of this, appreciate the update.

-chris

--
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

No problem. Raid results are uploading to
http://btrfs.boxacle.net/repository/raid/history/History.html now. There were massive improvements in the random write workloads, especially with cow enabled!! MailServer had moderate perf gains, but dramatic decrease in CPU utilization, so this is very good as well.

The only regression I see is on large file creates, CPU is up 200% or more while performance is fairly flat. btrfs_tree_lock now dominates the profile.

Quoted 4 lines · Steven Pratt

No problem. Raid results are uploading to http://btrfs.boxacle.net/repository/raid/history/History.html now. There were massive improvements in the random write workloads, especially with cow enabled!! MailServer had moderate perf gains, but dramatic decrease in CPU utilization, so this is very good as well.

The only regression I see is on large file creates, CPU is up 200% or more while performance is fairly flat. btrfs_tree_lock now dominates the profile.

I'm not able to reproduce the btrfs_tree_lock usage that you're seeing. Could you please use the callgraph option to oprofile?

-chris

I've setup git branches called newformat where you can pull the new =20 code.

For the kernel (based on 2.6.30-rc7):

git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-=20
unstable.git newformat

For the progs:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-=20
progs-unstable.git newformat

Quoted 7 lines · Chris Mason

I've setup git branches called newformat where you can pull the new code.

For the kernel (based on 2.6.30-rc7):

git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-
unstable.git newformat

# git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs- 
unstable.git newformat
fatal: Not a git repository

Quoted 4 lines

For the progs:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-
progs-unstable.git newformat

# git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs- 
progs-unstable.git newformat
fatal: Not a git repository

Quoted 1 line

Have this code been removed, or is it me doing something funny?

Hello everyone,

Yan Zheng has been doing some major surgery to the back references an=

extent allocation code, tackling bottlenecks in the code that tracks extents. =A0It scales better with many snapshots and performs better =

the common case of no snapshots at all.

THE NEW CODE IS A FORWARD ROLLING DISK FORMAT CHANGE. =A0This means i=

compatible with the current btrfs disk format, but once you mount a filesystem with the new code, it WILL NO LONGER BE MOUNTABLE FROM OLD KERNELS. =A0Old kernels spit out an error message when you try them o=

format filesystems.