Thinking of buying a QNAP TS-109? READ THIS FIRST!

[pakman]

Hi all,

Since this thread is discussing whether buying a QNAP to run slimserver is a good idea or not, I have to say that I am starting to regret my recent purchase. See my revival of a year-old thread discussing why the space used on a backup external disk is much much higher than the internal disk of the NAS istelf: http://forums.slimdevices.com/showth...510#post233510

The quick message is that you should think twice about having SlimSever installed on a QNAP if you plan to use Q-RAID 1 to back up the internal disk to an external one.

As I hinted in that post, if you do get a disk failure and restore from that backup, you will probably not get back exactly what you started with. Even if 'mount --bind' hides the contents of the duplicated directories, the space that they use on the new disk will not be available.

This has all the hallmarks of a problem that will never be fixed:

The SlimServer developers can say that their use of 'mount --bind' is standard since version 2.4.x of the Linux kernel, and it is not their problem if QNAP's Q-RAID 1 cannot cope with it, and/or the rsync utility has not had the functionality added to cope cleanly with a directory being mounted at an alternative location on the same filesystem.

QNAP can say that their software is written to work with the filesystem layout that they designed, and it is not their problem if some software that they do not support changes that layout and breaks Q-RAID 1.

I guess that I will probably end up uninstalling SlimServer, since being able to backup my NAS (and restore it correctly if I get a disk failure) is more important to me than the particular method I use to stream the data (and I don't have a Squeezebox). If I could rewind, I would probably not buy a QNAP now.

Grumble, grumble....
P.

[Ian_F]

Hi all,

Since this thread is discussing whether buying a QNAP to run slimserver is a good idea or not, I have to say that I am starting to regret my recent purchase. See my revival of a year-old thread discussing why the space used on a backup external disk is much much higher than the internal disk of the NAS istelf: http://forums.slimdevices.com/showth...510#post233510

The quick message is that you should think twice about having SlimSever installed on a QNAP if you plan to use Q-RAID 1 to back up the internal disk to an external one.

As I hinted in that post, if you do get a disk failure and restore from that backup, you will probably not get back exactly what you started with. Even if 'mount --bind' hides the contents of the duplicated directories, the space that they use on the new disk will not be available.

This has all the hallmarks of a problem that will never be fixed:

The SlimServer developers can say that their use of 'mount --bind' is standard since version 2.4.x of the Linux kernel, and it is not their problem if QNAP's Q-RAID 1 cannot cope with it, and/or the rsync utility has not had the functionality added to cope cleanly with a directory being mounted at an alternative location on the same filesystem.

QNAP can say that their software is written to work with the filesystem layout that they designed, and it is not their problem if some software that they do not support changes that layout and breaks Q-RAID 1.

I guess that I will probably end up uninstalling SlimServer, since being able to backup my NAS (and restore it correctly if I get a disk failure) is more important to me than the particular method I use to stream the data (and I don't have a Squeezebox). If I could rewind, I would probably not buy a QNAP now.

Grumble, grumble....
P.

Thanks for the heads-up. I'm not sure when you last raised this issue with QNAP but they now DO support slimserver so the "not our problem guv" message may no longer apply. Might be worth raising the issue with them again?

Secondly if you don't have a squeezebox, and don't intend buying one, then uninstall slimserver since all it's doing is using resources and in your case causing problems.

Lastly, and I don't want to start a flame war here, but utilising RAID 1 does not mean you're backing up your NAS and thus protecting your data.

But as I said above, thanks for the heads up. Definitely worth noting

[trefork]

Hi all,

Since this thread is discussing whether buying a QNAP to run slimserver is a good idea or not, I have to say that I am starting to regret my recent purchase. See my revival of a year-old thread discussing why the space used on a backup external disk is much much higher than the internal disk of the NAS istelf: http://forums.slimdevices.com/showth...510#post233510

The quick message is that you should think twice about having SlimSever installed on a QNAP if you plan to use Q-RAID 1 to back up the internal disk to an external one.

As I hinted in that post, if you do get a disk failure and restore from that backup, you will probably not get back exactly what you started with. Even if 'mount --bind' hides the contents of the duplicated directories, the space that they use on the new disk will not be available.

This has all the hallmarks of a problem that will never be fixed:

The SlimServer developers can say that their use of 'mount --bind' is standard since version 2.4.x of the Linux kernel, and it is not their problem if QNAP's Q-RAID 1 cannot cope with it, and/or the rsync utility has not had the functionality added to cope cleanly with a directory being mounted at an alternative location on the same filesystem.

QNAP can say that their software is written to work with the filesystem layout that they designed, and it is not their problem if some software that they do not support changes that layout and breaks Q-RAID 1.

I guess that I will probably end up uninstalling SlimServer, since being able to backup my NAS (and restore it correctly if I get a disk failure) is more important to me than the particular method I use to stream the data (and I don't have a Squeezebox). If I could rewind, I would probably not buy a QNAP now.

Grumble, grumble....
P.

Get the TS-201 or TS-209 instead.

[pakman]

Thanks for the heads-up. I'm not sure when you last raised this issue with QNAP but they now DO support slimserver so the "not our problem guv" message may no longer apply. Might be worth raising the issue with them again?

This is quite recent, and QNAP's response was that the mount table had been changed by a software installation (SlimServer). Therefore, QNAP cannot be said to support SlimServer (at least not completely). Do you have a pointer to somwhere where they say that they do?

Secondly if you don't have a squeezebox, and don't intend buying one, then uninstall slimserver since all it's doing is using resources and in your case causing problems.

You don't need a Squeezebox to use Slimserver: you can still stream to a software client.

Lastly, and I don't want to start a flame war here, but utilising RAID 1 does not mean you're backing up your NAS and thus protecting your data.

OK - there is a mis-understanding here. I am not talking about RAID, but QNAP's unfortunately-named Q-RAID 1 function. This is a way of duplicating the contents of the NAS's internal storage to an externally-connected disk (via USB or e-SATA). Going by the output of 'ps -ef', it is based on a patched version of rsync. As such, it _is_ supposed to be a backup system: you connect and power up your external disk to take a backup, and disconnect/power it down when finished. If your internal disk fails, you install a new one in the NAS and connect your external disk. The management interface will give you an option to restore the contents of the external disk to the new internal one. You are right that this is not RAID, because it is not intended to maintain availability when hardware fails.

Now, where it all goes wrong is that the SlimServer installation (at least as done by the vendor who sold me the NAS) uses bind mounts to remount some directories at alternative locations. These are (taken from /etc/mtab):

/dev /share/HDA_DATA/etch/dev none rw,bind 0 0
/proc /share/HDA_DATA/etch/proc none rw,bind 0 0
/proc/bus/usb /share/HDA_DATA/etch/proc/bus/usb none rw,bind 0 0
/share/HDA_DATA/Public/updates /share/HDA_DATA/etch/ext/updates none rw,bind 0 0
/share/HDA_DATA/Qmultimedia /share/HDA_DATA/etch/ext/Qmultimedia none rw,bind 0 0
/share/HDA_DATA/etch/opt/slimserver/Plugins /share/HDA_DATA/Public/plugins none rw,bind 0 0

rsync treats each directory involved has having an independent copy, and so Q-RAID 1 makes two copies on the target disk. (Since Qmultimedia is one of them, the target disk can fill up long before the internal one.) rsync has an '-x' option to stop it spanning filesystems, but that option has no effect when a directory has been bind mounted to another location on the same filesystem. AFAIK, rsync has no option to exclude bind mounts (although it arguably should). The only way to handle this that I can see is to analyse the mount table, and use rsync exclude options.

Does this make the situation clearer?

But as I said above, thanks for the heads up. Definitely worth noting

Hm.., but we still haven't answered the question as to who should do something about it? I stand by my original comment: don't buy a QNAP to run SlimServer if you intend using QNAP's backup tool (or indeed any rsync-based method of backing up, unless you are sure that it takes account of bind mounts).

[pakman]

Get the TS-201 or TS-209 instead.

See my post above where I explain why Q-RAID 1 is not in fact RAID.

Regards,
P.

[Ian_F]

This is quite recent, and QNAP's response was that the mount table had been changed by a software installation (SlimServer). Therefore, QNAP cannot be said to support SlimServer (at least not completely). Do you have a pointer to somwhere where they say that they do?

See here: http://forum.qnap.com/phpbb2/viewtop...server+support
There are plenty of other examples but this is the only one I managed to get my hands on.


However, I do agree 100% with you - QNAP/Progressive between them should work out who's gonna fix it.

It's very easy to point the finger at the other party but as you say, it's the customer that suffers in the end. I'm sure it can't be THAT difficult a thing to fix. Neither of them are novices, let's face it!

You don't need a Squeezebox to use Slimserver: you can still stream to a software client.

Fair point. Although one could argue that slimserver is not the best host if you're going to be using something other than softsqueeze.

OK - there is a mis-understanding here. I am not talking about RAID, but QNAP's unfortunately-named Q-RAID 1 function.

Another fair point. I vaguely remember reading about it when I first got mine. Will go and have another read now!


Pakman, given you clearly know your way around the device, is it THAT hard for QNAP/Progressive to fix?

[pakman]

See here: http://forum.qnap.com/phpbb2/viewtop...server+support
There are plenty of other examples but this is the only one I managed to get my hands on.


snip...

Pakman, given you clearly know your way around the device, is it THAT hard for QNAP/Progressive to fix?

My thoughts exactly! Although I'm new to NAS storage and special purpose/embedded distros like this, I've had 15 years of working with Unix and later Linux, so it didn't take me long to find out where the problem lies. I was surprised to find that no-one else seems to have diagnosed it, although I have found occasional complaints about excessive use of the backup disk by Q-RAID 1.

I guess that the thing that is really missing here is an option to stop rsync descending into bind mounted directories. Maybe QNAP/Progressive could contribute one to the rsync source. A lot of people would benefit.

Regards,
P.

P.S. Maybe kicking up this fuss in the forum will prod someone into action :-)

[pakman]

P.S. Maybe kicking up this fuss in the forum will prod someone into action :-)

I've put a feature request in the QNAP forums here: http://forum.qnap.com/phpbb2/viewtopic.php?t=881 No replies yet: we'll see.

[majones]

My QNAP TS-119 suffers this incompatibility problem (high rsync CPU) when running Squeezebox Server 7.5.1 via SSOTS when QRAID-1 is activated. Is there a solution?