unRAID Server Release 6.0-beta14b-x86_64 Available

[jonp]

 

 

no Xen update?

 

No.  Not for beta 15.

 

Also, just a quick update.  We found a bug as we were going through final release testing that is holding this up right now.  I'll spare all the details, but in short, it has to do with the fact that the btrfs progs for 3.19.1 are not 100% compatible with the Linux 4.0 kernel.  We are looking to roll back to the previous kernel, but to do so, we would need to manually apply a patch that is slated for inclusion in the 3.19.5 kernel (which is not yet released).  We're looking into all this and testing thoroughly.

 

You guys are joking, right? If you keep changing kernels like we change underwear, there will never be a stable release. Think long and hard about the bugs that do indicate kernel updates are important enough to effectively postpone the whole project to the end of time. Bet you the 4.0 or even 3.19.5 kernel will introduce yet another little gotcha, and you will be back where you started.

 

Get a stable release out already, even if there is going to be a couple of known issues.

 

We don't upgrade the kernel without just cause.

 

Causes you have not disclosed, since you don't have a bug tracker. But is seems a lot of hinges on BTRFS and features of that filesystem that were not stable when you started V6 development, and it seems still are not stable. I know you have promised a cache-pool as a feature, but V6 would be a fine product without that feature. Stabilize it, then take the next step when BTRFS is ready for prime time.

It benefits no one for us to post issues with internal releases on a public forum. When a public release and is issued, bugs are tracked in the defect reports forum as they always have been.

 

With respect to btrfs, OpenSUSE and some others have switched to BTRFS as the default for their platforms, which is a pretty good indication of stable code.  Pool operations have been a bit daunting here and there, but that's how it goes with development.

 

There is no way we would pull the cache pool feature at this point in development. Plenty of hard work has gone into substantially improving pool operations for 6.0 and there is only one primary bug holding up the release for which there is a known fix on the way.

[MortenSchmidt]

 

 

no Xen update?

 

No.  Not for beta 15.

 

Also, just a quick update.  We found a bug as we were going through final release testing that is holding this up right now.  I'll spare all the details, but in short, it has to do with the fact that the btrfs progs for 3.19.1 are not 100% compatible with the Linux 4.0 kernel.  We are looking to roll back to the previous kernel, but to do so, we would need to manually apply a patch that is slated for inclusion in the 3.19.5 kernel (which is not yet released).  We're looking into all this and testing thoroughly.

 

You guys are joking, right? If you keep changing kernels like we change underwear, there will never be a stable release. Think long and hard about the bugs that do indicate kernel updates are important enough to effectively postpone the whole project to the end of time. Bet you the 4.0 or even 3.19.5 kernel will introduce yet another little gotcha, and you will be back where you started.

 

Get a stable release out already, even if there is going to be a couple of known issues.

 

We don't upgrade the kernel without just cause.

 

Causes you have not disclosed, since you don't have a bug tracker. But is seems a lot of hinges on BTRFS and features of that filesystem that were not stable when you started V6 development, and it seems still are not stable. I know you have promised a cache-pool as a feature, but V6 would be a fine product without that feature. Stabilize it, then take the next step when BTRFS is ready for prime time.

It benefits no one for us to post issues with internal releases on a public forum. When a public release and is issued, bugs are tracked in the defect reports forum as they always have been.

 

With respect to btrfs, OpenSUSE and some others have switched to BTRFS as the default for their platforms, which is a pretty good indication of stable code.  Pool operations have been a bit daunting here and there, but that's how it goes with development.

 

There is no way we would pull the cache pool feature at this point in development. Plenty of hard work has gone into substantially improving pool operations for 6.0 and there is only one primary bug holding up the release for which there is a known fix on the way.

 

I wonder if this has been the case all the other times the kernel was updated as well.

[jonp]

 

 

 

 

no Xen update?

 

No.  Not for beta 15.

 

Also, just a quick update.  We found a bug as we were going through final release testing that is holding this up right now.  I'll spare all the details, but in short, it has to do with the fact that the btrfs progs for 3.19.1 are not 100% compatible with the Linux 4.0 kernel.  We are looking to roll back to the previous kernel, but to do so, we would need to manually apply a patch that is slated for inclusion in the 3.19.5 kernel (which is not yet released).  We're looking into all this and testing thoroughly.

 

You guys are joking, right? If you keep changing kernels like we change underwear, there will never be a stable release. Think long and hard about the bugs that do indicate kernel updates are important enough to effectively postpone the whole project to the end of time. Bet you the 4.0 or even 3.19.5 kernel will introduce yet another little gotcha, and you will be back where you started.

 

Get a stable release out already, even if there is going to be a couple of known issues.

 

We don't upgrade the kernel without just cause.

 

Causes you have not disclosed, since you don't have a bug tracker. But is seems a lot of hinges on BTRFS and features of that filesystem that were not stable when you started V6 development, and it seems still are not stable. I know you have promised a cache-pool as a feature, but V6 would be a fine product without that feature. Stabilize it, then take the next step when BTRFS is ready for prime time.

It benefits no one for us to post issues with internal releases on a public forum. When a public release and is issued, bugs are tracked in the defect reports forum as they always have been.

 

With respect to btrfs, OpenSUSE and some others have switched to BTRFS as the default for their platforms, which is a pretty good indication of stable code.  Pool operations have been a bit daunting here and there, but that's how it goes with development.

 

There is no way we would pull the cache pool feature at this point in development. Plenty of hard work has gone into substantially improving pool operations for 6.0 and there is only one primary bug holding up the release for which there is a known fix on the way.

 

I wonder if this has been the case all the other times the kernel was updated as well.

 

I'm not understanding your question.

[JonathanM]

I'm not understanding your question.

At the risk of putting words in someone's mouth, I think he is positing that it is a never ending cycle of update kernel, find showstopping bugs, attempt to fix bugs, newer kernel seems to address the issue, update kernel, find showstopping bugs, attempt to fix bugs.........

 

At some point you have to stop and deal with it, or we get development cycles that span years. The fact that beta15 was "all set to go" yesterday and now we are in another wait cycle because of a kernel change because of a file system bug is frustrating, for everyone.

[Squid]

Some light reading material for you while you wait:  http://lime-technology.com/wiki/index.php/UnRAID_Manual_6

 

Note:  the above is a work in progress.

Personally, I would shorten sections 2.1 and 2.2 (Docker and VM's) to be more of a blurb with alot less of the tech info in it, and then point the readers to an entirely different section that will have the complete introduction.

 

Your target for the manual ultimately is the noob / potential purchaser, and those sections are going to scare them off (just by starting to talk about LXC, QEMU, libvirt, VFIO*, VirtIO, and VirtFS right at the beginning)

[archedraft]

 

The fact that beta15 was "all set to go" yesterday and now we are in another wait cycle because of a kernel change because of a file system bug is frustrating, for everyone.

 

Turn the tables around, how frustrated must everyone be at LT after all the hard work and nearly getting everything ready to go, only to find a bug right at the end. I'm sure they feel just as frustrated as us, if not more.

[trurl]

Some light reading material for you while you wait:  http://lime-technology.com/wiki/index.php/UnRAID_Manual_6

 

Note:  the above is a work in progress.

Personally, I would shorten sections 2.1 and 2.2 (Docker and VM's) to be more of a blurb with alot less of the tech info in it, and then point the readers to an entirely different section that will have the complete introduction.

 

Your target for the manual ultimately is the noob / potential purchaser, and those sections are going to scare them off (just by starting to talk about LXC, QEMU, libvirt, VFIO*, VirtIO, and VirtFS right at the beginning)

This seems like a good idea.

[xamindar]

no Xen update?

 

No.  Not for beta 15.

 

Also, just a quick update.  We found a bug as we were going through final release testing that is holding this up right now.  I'll spare all the details, but in short, it has to do with the fact that the btrfs progs for 3.19.1 are not 100% compatible with the Linux 4.0 kernel.  We are looking to roll back to the previous kernel, but to do so, we would need to manually apply a patch that is slated for inclusion in the 3.19.5 kernel (which is not yet released).  We're looking into all this and testing thoroughly.

 

You guys are joking, right? If you keep changing kernels like we change underwear, there will never be a stable release. Think long and hard about the bugs that do indicate kernel updates are important enough to effectively postpone the whole project to the end of time. Bet you the 4.0 or even 3.19.5 kernel will introduce yet another little gotcha, and you will be back where you started.

 

Get a stable release out already, even if there is going to be a couple of known issues.

 

Wow, the childish "I want it now!" entitlement mentality is very rude. They are sharing internal information with us and you are throwing a temper tantrum?

 

I would rather them upgrade/patch the kernel to resolve the btrfs mount deadlock issue rather than rushing an untested beta out to us. An unmountable filesystem is a serious issue. The 4.0 kernel resolves that problem (or a 3.19.x with a particular patch) and that is why they upgraded.

 

Is 14b such an issue that you need an upgrade right now?

[MortenSchmidt]

 

The fact that beta15 was "all set to go" yesterday and now we are in another wait cycle because of a kernel change because of a file system bug is frustrating, for everyone.

 

Turn the tables around, how frustrated must everyone be at LT after all the hard work and nearly getting everything ready to go, only to find a bug right at the end. I'm sure they feel just as frustrated as us, if not more.

 

Being a bit of a perfectionist myself, I feel I can relate to that pain. But that being said, there are good and bad ways to react to those situations. Drop or postpone the feature that that one last remaining bug is affecting.

 

We should give LT at least some credit for not suffering a huge amount of feature creep. It's just that 'Kernel Creep' is a lot worse, as you are almost guaranteed to get new issues with every 'update'.

[jbartlett]

Some light reading material for you while you wait:  http://lime-technology.com/wiki/index.php/UnRAID_Manual_6

 

Note:  the above is a work in progress.

 

The cache description doesn't seem to be fully fleshed out. For example, the cache drive isn't utilized if updating/replacing a file that currently exists in the protected array - ie: it doesn't exist in both the protected array AND the cache drive.

[xamindar]

 

The fact that beta15 was "all set to go" yesterday and now we are in another wait cycle because of a kernel change because of a file system bug is frustrating, for everyone.

 

Turn the tables around, how frustrated must everyone be at LT after all the hard work and nearly getting everything ready to go, only to find a bug right at the end. I'm sure they feel just as frustrated as us, if not more.

 

Being a bit of a perfectionist myself, I feel I can relate to that pain. But that being said, there are good and bad ways to react to those situations. Drop or postpone the feature that that one last remaining bug is affecting.

 

We should give LT at least some credit for not suffering a huge amount of feature creep. It's just that 'Kernel Creep' is a lot worse, as you are almost guaranteed to get new issues with every 'update'.

 

I have been running Linux systems for over 15 years and rarely has a kernel update caused a problem. I can only think of one instance where this happened. And I run rolling release systems (Gentoo, Arch) which would be more likely to have a problem. The Linux kernel is probably one of the most stable parts of the system as it should be. And besides, he already pointed out that it isn't the fault of the 4.0 kernel, it is the fault of btrfs progs.

 

Where is your source that kernel updates constantly cause issues? I have never experienced this.

 

And they can't "drop or postpone" btrfs support as it has already been added and people are already using it. A lot of things already rely on it.

[MortenSchmidt]

no Xen update?

 

No.  Not for beta 15.

 

Also, just a quick update.  We found a bug as we were going through final release testing that is holding this up right now.  I'll spare all the details, but in short, it has to do with the fact that the btrfs progs for 3.19.1 are not 100% compatible with the Linux 4.0 kernel.  We are looking to roll back to the previous kernel, but to do so, we would need to manually apply a patch that is slated for inclusion in the 3.19.5 kernel (which is not yet released).  We're looking into all this and testing thoroughly.

 

You guys are joking, right? If you keep changing kernels like we change underwear, there will never be a stable release. Think long and hard about the bugs that do indicate kernel updates are important enough to effectively postpone the whole project to the end of time. Bet you the 4.0 or even 3.19.5 kernel will introduce yet another little gotcha, and you will be back where you started.

 

Get a stable release out already, even if there is going to be a couple of known issues.

 

Wow, the childish "I want it now!" entitlement mentality is very rude. They are sharing internal information with us and you are throwing a temper tantrum?

 

I would rather them upgrade/patch the kernel to resolve the btrfs mount deadlock issue rather than rushing an untested beta out to us. An unmountable filesystem is a serious issue. The 4.0 kernel resolves that problem (or a 3.19.x with a particular patch) and that is why they upgraded.

 

Is 14b such an issue that you need an upgrade right now?

 

I don't want it now, I want it last September. Tic toc. Without BTRS cache pool and possibly one or two other features, I think it would have been possible for them too. They could then have been well underway with the next version by now, or they could have delayed development of the cachepool feature until BTRS was stable, I could have probably saved them a lot of time. Trying to develop a stable NAS product around an unstable filesystem feature is like trying to fit a cylinder through a square hole.

[xamindar]

no Xen update?

 

No.  Not for beta 15.

 

Also, just a quick update.  We found a bug as we were going through final release testing that is holding this up right now.  I'll spare all the details, but in short, it has to do with the fact that the btrfs progs for 3.19.1 are not 100% compatible with the Linux 4.0 kernel.  We are looking to roll back to the previous kernel, but to do so, we would need to manually apply a patch that is slated for inclusion in the 3.19.5 kernel (which is not yet released).  We're looking into all this and testing thoroughly.

 

You guys are joking, right? If you keep changing kernels like we change underwear, there will never be a stable release. Think long and hard about the bugs that do indicate kernel updates are important enough to effectively postpone the whole project to the end of time. Bet you the 4.0 or even 3.19.5 kernel will introduce yet another little gotcha, and you will be back where you started.

 

Get a stable release out already, even if there is going to be a couple of known issues.

 

Wow, the childish "I want it now!" entitlement mentality is very rude. They are sharing internal information with us and you are throwing a temper tantrum?

 

I would rather them upgrade/patch the kernel to resolve the btrfs mount deadlock issue rather than rushing an untested beta out to us. An unmountable filesystem is a serious issue. The 4.0 kernel resolves that problem (or a 3.19.x with a particular patch) and that is why they upgraded.

 

Is 14b such an issue that you need an upgrade right now?

 

I don't want it now, I want it last September. Tic toc. Without BTRS cache pool and possibly one or two other features, I think it would have been possible for them too. They could then have been well underway with the next version by now, or they could have delayed development of the cachepool feature until BTRS was stable, I could have probably saved them a lot of time. Trying to develop a stable NAS product around an unstable filesystem feature is like trying to fit a cylinder through a square hole.

 

Btrfs is pretty stable. They are still adding features and that sometimes brings a few bugs. This particular one prevents mount by the effected kernel and while a pretty serious bug, it doesn't cause any data loss. I am already running 3 of my Linux systems on btrfs and have not had any issues. I have been following btrfs development quite closely as of late and the recent new features are pretty exciting. Enterprise systems are also starting to use it in certain situations.

[MortenSchmidt]

I have been running Linux systems for over 15 years and rarely has a kernel update caused a problem. I can only think of one instance where this happened. And I run rolling release systems (Gentoo, Arch) which would be more likely to have a problem. The Linux kernel is probably one of the most stable parts of the system as it should be. And besides, he already pointed out that it isn't the fault of the 4.0 kernel, it is the fault of btrfs progs.

 

Where is your source that kernel updates constantly cause issues? I have never experienced this.

 

Hello??? ReiserFS issues in beta 8 or whichever one it was? Pretty serious issue too, causing silent data corruption. I rest my case.

 

And they can't "drop or postpone" btrfs support as it has already been added and people are already using it. A lot of things already rely on it.

 

I know it is a cornerstone of the Docker implementation and I am not suggesting removing BTRFS, only the cache pool feature that seems to have caused so much trouble and is a minor feature. V6 could have been released without that feature, remember V6 still brings 64-bit, 3 different VM approaches and a slick improved webgui, amongst other things. Huge update over V5, I say bring it to the (paying) customers on time (or at least no more than 6-and-a-half months late...)?

 

Btrfs is pretty stable. They are still adding features and that sometimes brings a few bugs. This particular one prevents mount by the effected kernel and while a pretty serious bug, it doesn't cause any data loss. I am already running 3 of my Linux systems on btrfs and have not had any issues. I have been following btrfs development quite closely as of late and the recent new features are pretty exciting. Enterprise systems are also starting to use it in certain situations.

 

This is all good, but can we at least agree it has caused a lot of issues with unraid V6, given the inclusion of the multi-drive pool feature, which I bet is not one of the features being implemented in enterprise systems at the moment?

[jonp]

no Xen update?

 

No.  Not for beta 15.

 

Also, just a quick update.  We found a bug as we were going through final release testing that is holding this up right now.  I'll spare all the details, but in short, it has to do with the fact that the btrfs progs for 3.19.1 are not 100% compatible with the Linux 4.0 kernel.  We are looking to roll back to the previous kernel, but to do so, we would need to manually apply a patch that is slated for inclusion in the 3.19.5 kernel (which is not yet released).  We're looking into all this and testing thoroughly.

 

You guys are joking, right? If you keep changing kernels like we change underwear, there will never be a stable release. Think long and hard about the bugs that do indicate kernel updates are important enough to effectively postpone the whole project to the end of time. Bet you the 4.0 or even 3.19.5 kernel will introduce yet another little gotcha, and you will be back where you started.

 

Get a stable release out already, even if there is going to be a couple of known issues.

 

Wow, the childish "I want it now!" entitlement mentality is very rude. They are sharing internal information with us and you are throwing a temper tantrum?

 

I would rather them upgrade/patch the kernel to resolve the btrfs mount deadlock issue rather than rushing an untested beta out to us. An unmountable filesystem is a serious issue. The 4.0 kernel resolves that problem (or a 3.19.x with a particular patch) and that is why they upgraded.

 

Is 14b such an issue that you need an upgrade right now?

 

I don't want it now, I want it last September. Tic toc. Without BTRS cache pool and possibly one or two other features, I think it would have been possible for them too. They could then have been well underway with the next version by now, or they could have delayed development of the cachepool feature until BTRS was stable, I could have probably saved them a lot of time. Trying to develop a stable NAS product around an unstable filesystem feature is like trying to fit a cylinder through a square hole.

 

Btrfs is pretty stable. They are still adding features and that sometimes brings a few bugs. This particular one prevents mount by the effected kernel and while a pretty serious bug, it doesn't cause any data loss. I am already running 3 of my Linux systems on btrfs and have not had any issues. I have been following btrfs development quite closely as of late and the recent new features are pretty exciting. Enterprise systems are also starting to use it in certain situations.

 

^^^ THIS IS TRUTH ^^^

 

The issues and bugs we've faced with btrfs have been certainly challenging, but let me state for the record, I have never lost data on btrfs acting as my cache pool since it was first implemented in unRAID 6.  I realize that a few others had some issues in some edge case scenarios, but I have not had that experience myself.  I have multiple test systems with cache pools of various devices / sizes and I even have array devices formatted with btrfs.

 

But beyond that, btrfs has a slew of features for which we haven't even tapped into fully just yet.  Subvolumes and snapshots being two really big ones.

 

Example:  I create a RAW VM image on my cache pool but in a subvolume instead of a regular folder.  Then I take 3 snapshots of that subvolume.  Now I mount the three snapshots as /mnt/vm1 /mnt/vm2 and /mnt/vm3 (so each directory here will contain the vdisks for the VM).  My net storage usage is then the original subvolume + any changes I make to the vdisks of any one subvolume.  So if my original vdisk was 30G, after the snapshots are taken, my net usage should be around 30G still.  Now I go and install some programs on the vdisk in a snapshot and thanks to copy-on-write, the only new disk space consumed should be that of the new programs I install.  Because the snapshots are inside the btrfs pool, the command to perform them happens instantly (there is no delay or period of wait for the operation to complete).  The same could be done with appdata.  For example, we have internally discussed a concept where we snapshot appdata so that if someone needs to roll back to an earlier state, they could.

 

When we selected btrfs for inclusion, these sorts of things were in mind as later feature enhancements that we could easily add to unRAID given the capabilities of the file system.

[AndroidCat]

Btrfs is pretty stable. They are still adding features and that sometimes brings a few bugs. This particular one prevents mount by the effected kernel and while a pretty serious bug, it doesn't cause any data loss. I am already running 3 of my Linux systems on btrfs and have not had any issues. I have been following btrfs development quite closely as of late and the recent new features are pretty exciting. Enterprise systems are also starting to use it in certain situations.

 

There is no such thing acceptable in production systems as "FS being pretty stable". It is either stable and proven or unstable.

 

Like in Bulgakov's book 

 

`Second freshness - that's what is nonsense! There is only one freshness - the first - and it is also the last. And if sturgeon is of the second freshness, that means it is simply rotten.'

[xamindar]

This is all good, but can we at least agree it has caused a lot of issues with unraid V6, given the inclusion of the multi-drive pool feature, which I bet is not one of the features being implemented in enterprise systems at the moment?

The multi-drive cache pool feature has nothing to do with the btrfs bug so I don't understand your point.

[jonp]

I have been running Linux systems for over 15 years and rarely has a kernel update caused a problem. I can only think of one instance where this happened. And I run rolling release systems (Gentoo, Arch) which would be more likely to have a problem. The Linux kernel is probably one of the most stable parts of the system as it should be. And besides, he already pointed out that it isn't the fault of the 4.0 kernel, it is the fault of btrfs progs.

 

Where is your source that kernel updates constantly cause issues? I have never experienced this.

 

Hello??? ReiserFS issues in beta 8 or whichever one it was? Pretty serious issue too, causing silent data corruption. I rest my case.

 

This was a particularly nasty issue, yes.  I won't rehash all the details because everything that needed to be said was said.  One issue though is hardly enough to label as "constant".  Bugs happen in betas, it's the nature of things.  Once and a while, a major one slips by.  It is rare.  In fact, I believe this is the first one in our history.

 

And they can't "drop or postpone" btrfs support as it has already been added and people are already using it. A lot of things already rely on it.

 

I know it is a cornerstone of the Docker implementation and I am not suggesting removing BTRFS, only the cache pool feature that seems to have caused so much trouble and is a minor feature.

 

Not by a long shot.  Cache pools is one of the cornerstone features of unRAID 6.  You would be highly mistaken to label it as a minor feature.

[MortenSchmidt]

Btrfs is pretty stable.

 

^^^ THIS IS TRUTH ^^^

 

Why isn't it working, then?

[EMKO]

This is all good, but can we at least agree it has caused a lot of issues with unraid V6, given the inclusion of the multi-drive pool feature, which I bet is not one of the features being implemented in enterprise systems at the moment?

The multi-drive cache pool feature has nothing to do with the btrfs bug so I don't understand your point.

 

cache drives are useless at the moment they cause massive slow downs on the drives speed, since Unraid can't understand just to move files on the cache drive instead of coping them.

 

What happens when a file is on the Cache Drive and a program moves it to a CACHED share  the file should just move quickly from one folder on the same drive to another instead Unraid reads and writes the file on the same hard drive causing the harddrive to use all of its speed. When this happens any app running on the drive like Plex end up buffering etc.

 

If Unraid can fix it so the files just get moved, cache drives would be useful but right now i cant use them.

[jonp]

Btrfs is pretty stable.

 

^^^ THIS IS TRUTH ^^^

 

Why isn't it working, then?

 

It is working.

 

This is all good, but can we at least agree it has caused a lot of issues with unraid V6, given the inclusion of the multi-drive pool feature, which I bet is not one of the features being implemented in enterprise systems at the moment?

The multi-drive cache pool feature has nothing to do with the btrfs bug so I don't understand your point.

 

cache drives are useless at the moment they cause massive slow downs on the drives speed, since Unraid can't understand just to move files on the cache drive instead of coping them.

 

What happens when a file is on the Cache Drive and a program moves it to a CACHED share  the file should just move quickly from one folder on the same drive to another instead Unraid reads and writes the file on the same hard drive causing the harddrive to use all of its speed. When this happens any app running on the drive like Plex end up buffering etc.

 

If Unraid can fix it so the files just get moved, cache drives would be useful but right now i cant use them.

 

Let's not label a feature useless just because your use case has an issue.  Cache drives improve write performance to user shares  during real-time write operations, then migrate data to array devices on a schedule.  Moving data from one area of cache to another is not the atypical function for cache.

[MortenSchmidt]

Btrfs is pretty stable.

 

^^^ THIS IS TRUTH ^^^

 

Why isn't it working, then?

 

It is working.

 

Then let's stay on the current kernel and work toward a stable release..

[jonp]

Btrfs is pretty stable.

 

^^^ THIS IS TRUTH ^^^

 

Why isn't it working, then?

 

It is working.

 

Then let's stay on the current kernel and work toward a stable release..

Morten,

 

I already said that was an avenue we are pursuing at this point (patching the existing 3.19 kernel in lieu of an upgrade to 4.0).  Did you miss that part of my post before you replied initially?

[EMKO]

Btrfs is pretty stable.

 

^^^ THIS IS TRUTH ^^^

 

Why isn't it working, then?

 

It is working.

 

This is all good, but can we at least agree it has caused a lot of issues with unraid V6, given the inclusion of the multi-drive pool feature, which I bet is not one of the features being implemented in enterprise systems at the moment?

The multi-drive cache pool feature has nothing to do with the btrfs bug so I don't understand your point.

 

cache drives are useless at the moment they cause massive slow downs on the drives speed, since Unraid can't understand just to move files on the cache drive instead of coping them.

 

What happens when a file is on the Cache Drive and a program moves it to a CACHED share  the file should just move quickly from one folder on the same drive to another instead Unraid reads and writes the file on the same hard drive causing the harddrive to use all of its speed. When this happens any app running on the drive like Plex end up buffering etc.

 

If Unraid can fix it so the files just get moved, cache drives would be useful but right now i cant use them.

 

Let's not label a feature useless just because your use case has an issue.  Cache drives improve write performance to user shares  during real-time write operations, then migrate data to array devices on a schedule.  Moving data from one area of cache to another is not the atypical function for cache.

 

Dockers run on cache drive no? and when a app needs to move a file so that it will be migrated to the array? we get slow downs and unnecessary wearing of the drive.

 

Unraid should be able to know the file is already on the cache drive and move it instead of copying it over to another folder?

[jonp]

Btrfs is pretty stable.

 

^^^ THIS IS TRUTH ^^^

 

Why isn't it working, then?

 

It is working.

 

This is all good, but can we at least agree it has caused a lot of issues with unraid V6, given the inclusion of the multi-drive pool feature, which I bet is not one of the features being implemented in enterprise systems at the moment?

The multi-drive cache pool feature has nothing to do with the btrfs bug so I don't understand your point.

 

cache drives are useless at the moment they cause massive slow downs on the drives speed, since Unraid can't understand just to move files on the cache drive instead of coping them.

 

What happens when a file is on the Cache Drive and a program moves it to a CACHED share  the file should just move quickly from one folder on the same drive to another instead Unraid reads and writes the file on the same hard drive causing the harddrive to use all of its speed. When this happens any app running on the drive like Plex end up buffering etc.

 

If Unraid can fix it so the files just get moved, cache drives would be useful but right now i cant use them.

 

Let's not label a feature useless just because your use case has an issue.  Cache drives improve write performance to user shares  during real-time write operations, then migrate data to array devices on a schedule.  Moving data from one area of cache to another is not the atypical function for cache.

 

Dockers run on cache drive no? and when a app needs to move a file so that it will be migrated to the array? we get slow downs and unnecessary wearing of the drive.

 

Unraid should be able to know the file is already on the cache drive and move it instead of copying it over to another folder?

Why does the file need to be moved to begin with?  Why aren't you setting docker volumes to write data to cache enabled user shares directly?  You should not be saving files inside the containers themselves.