Error running a command. (Create a Share)

[phillxnet (Philip Guyton)]

@b8two That is a lot of questions:

I’m afraid I can’t address all of these right now and many have answers already on the forum but lets get this USB key thing out of the way.

Have you seen this post:

Rockstor taking a REALLY long time to install

@cmdywrtr27 Welcome to the Rockstor community. I think the key element here is that it is best if the system drive is dedicated. You can usually create shares on the ‘dedicated’ system drive but they are more restricted in their flexibility and of course would vanish on a re-install. So Rockstor is best if the system drive is an independant / dedicated block device. As for choice of USB drive if that is the way you are to go. Your choice in this case is clearly wrong as even if it complete th…

quoting further down we have:

@phillxnet

So in short don’t use a USB key if you can help it. If you have to use a USB key make sure it’s a fast good quality one. If buying new check specs and if there arn’t any write specs then it’s rubbish. Otherwise check write speeds before the install or just plough forward and bail early if it’s taking ages in favour of a better option. And also take into account the install medium. If you are installing from another slow USB key then you are compounding your slow install issue. Although pretty much all keys are faster to read than write.

A rough indicator of a keys speed could be how long it takes to write the iso image to it.

Below I’ve copied in some recent tests all performed on the same machine using the same USB 3.0 port:

I’ll post again the speed tests run there, can you try yours out so we can get a feel for what we are after recommending here:

# SanDisk Extreme USB 3.0 32 GB

sudo time dd if=Rockstor-3.9.1.iso of=/dev/sdc bs=64k
12656+0 records in
12656+0 records out
829423616 bytes (829 MB, 791 MiB) copied, 8.68624 s, 95.5 MB/s
0.00user 1.01system 0:08.68elapsed 11%CPU (0avgtext+0avgdata 2276maxresident)k
0inputs+1619968outputs (0major+114minor)pagefaults 0swaps

/dev/sdc:
Timing cached reads:   27596 MB in  1.99 seconds = 13875.22 MB/sec
Timing buffered disk reads: 790 MB in  3.00 seconds = 262.93 MB/sec



# SanDisk Extreme GO USB 3.1 64GB

sudo time dd if=Rockstor-3.9.1.iso of=/dev/sdc bs=64k
12656+0 records in
12656+0 records out
829423616 bytes (829 MB, 791 MiB) copied, 5.24771 s, 158 MB/s
0.01user 0.39system 0:05.24elapsed 7%CPU (0avgtext+0avgdata 2048maxresident)k
0inputs+1619968outputs (0major+112minor)pagefaults 0swaps

sudo hdparm -Tt /dev/sdc

/dev/sdc:
Timing cached reads:   27664 MB in  1.99 seconds = 13912.05 MB/sec
Timing buffered disk reads: 610 MB in  3.01 seconds = 202.88 MB/sec



# SanDisk Ultra Fit  (ID 0781:5583)

sudo time dd if=Rockstor-3.9.1.iso of=/dev/sdc bs=64k
12656+0 records in
12656+0 records out
829423616 bytes (829 MB, 791 MiB) copied, 12.1263 s, 68.4 MB/s
0.00user 0.40system 0:12.12elapsed 3%CPU (0avgtext+0avgdata 2012maxresident)k
0inputs+1619968outputs (0major+109minor)pagefaults 0swaps

/dev/sdc:
Timing cached reads:   27760 MB in  1.99 seconds = 13958.43 MB/sec
Timing buffered disk reads: 418 MB in  3.00 seconds = 139.28 MB/sec



# IS917 innostor 16GB (USB 3.0) more ‘regular’ USB 3.0 key

sudo time dd if=Rockstor-3.9.1.iso of=/dev/sdc bs=64k
12656+0 records in
12656+0 records out
829423616 bytes (829 MB, 791 MiB) copied, 35.1284 s, 23.6 MB/s
0.01user 0.38system 0:35.12elapsed 1%CPU (0avgtext+0avgdata 2144maxresident)k
0inputs+1619968outputs (0major+115minor)pagefaults 0swaps

/dev/sdc:
Timing cached reads:   26472 MB in  1.99 seconds = 13307.74 MB/sec
Timing buffered disk reads: 364 MB in  3.01 seconds = 120.96 MB/sec


# SanDisk Cruzer Fit 16GB (USB 2.0 I think) in USB 3.0 port:
# (ID 0781:5571)

sudo time dd if=Rockstor-3.9.1.iso of=/dev/sdc bs=64k
12656+0 records in
12656+0 records out
829423616 bytes (829 MB, 791 MiB) copied, 150.716 s, 5.5 MB/s
0.00user 0.38system 2:30.71elapsed 0%CPU (0avgtext+0avgdata 2212maxresident)k
0inputs+1619968outputs (0major+113minor)pagefaults 0swaps

sudo hdparm -Tt /dev/sdc                               

/dev/sdc:
Timing cached reads:   26490 MB in  1.99 seconds = 13315.59 MB/sec
Timing buffered disk reads:  72 MB in  3.04 seconds =  23.70 MB/sec


# And for comparison:

# Crucial MX500 SSD in external Orico USB3.0 caddy.
# (ID 357d:7788 Sharkoon QuickPort XT)

sudo time dd if=Rockstor-3.9.1.iso of=/dev/sdc bs=64k
12656+0 records in
12656+0 records out
829423616 bytes (829 MB, 791 MiB) copied, 3.3814 s, 245 MB/s
0.00user 0.40system 0:03.38elapsed 12%CPU (0avgtext+0avgdata 2204maxresident)k
0inputs+1619968outputs (0major+113minor)pagefaults 0swaps


sudo hdparm -Tt /dev/sdc

/dev/sdc:
Timing cached reads:   26318 MB in  1.99 seconds = 13230.02 MB/sec
Timing buffered disk reads: 806 MB in  3.00 seconds = 268.31 MB/sec

Again quoting the summary of that post we have:

@phillxnet

So note we have here a range of write speed from an older compact USB 2.0 5.5 MB/s to 158 MB/s with the Extreme GO, with the MX500 in enclosure getting 245 MB/s. And the read speeds have a similar span. If the MX500 was to be put directly on an SATA it would be significantly faster again. The USB bus is generally considered to be inferior for block storage. But if you are only running a single device pool on it and have no actual ‘data’ there then it’s mostly OK.

So as the minimum system requirements say, you are after as fast a device as you can get really. But as long as it’s roughly HDD speed or above you should be OK.

So if your could contribute your finding speed wise by the same measure we can start to establish a ressonable minimum. And as you see from that Dec 19 post the USB port is by far not the limiting factor with some USB2.0 keys, in a USB 3.0 port, managing only 5.5 MB/s write. Hence the recommendation.

An keeping your your USB2.0 port being a restriction for faster divices, that a very good point. Maybe we should add that to our recommendation. I see from:

usb20.pdf

Section 5.8.4 “Bulk Transfer Bus Access Constraints”
Table 5-10
We are talking, for the bus itself, as you say, 40 to 53 MB/s. But again if some keys are 1/10th of that then the key is still far more important. But 40 MB/s is still a little slow.

So lets add your current device spec (model name) and the same speed tests to that table and we can start to build up an example of keys speeds that are good and less good, and of course bad. I did those tests and posted the results as a way of trying to establish what we are looking for and so if you also post yours we can see if the USB 2.0 port is actually the bottleneck in your case.

@b8two

Overall, I just don’t understand why drives not in the same pool as the operating system affect the operating system performance. (Tehnically I’m not even using the same interface as the drives USB vs SATA).

Btrfs takes a lot more ‘work’ than the vast majority of other file-systems as it is generally doing a great deal more. This ‘balance’ operation is a generic term and means the pool is re-organising in a fairly major way. And with atomic disk every constituting a number of reads and writes things can take time. It’s a cost of the flexibility. Plus there is no magic here. Also note that not everything shows in top. If a system is irq saturated it’s going to be harder to see that. But I’m no expert but there may be some on the forum that can explain this in more informed detail. But needless to say, one drive on a system can very much affect the rest of the system. Try running a drive with irq / dma issue and see your entire system drop to a crawl. Maybe you have such a drive in your system. But yes the btrfs subsystem, especially in the ‘olden days’ of our CentOS variant, is pretty slow. And yes the btrfs subsystem of our openSUSE variant is significantly faster, which bring me to the following:

@b8two

Is there like a Feature table comparison of CentOS vs OpenSUSE to understand the progress of the transition. Would I be better off adopting OpenSUSE now instead of making the hardware change.

Not really as we are attempting to fix all that is reported. But in short almost everything works currently but it’s still buggy. But then so is our CentOS offering. Our main concern though is to arrive at what we are loosely referencing as ‘feature parity or near enough’. And to that end we intend to be ‘there’ in a few weeks time. Hopefully in time for the release of our intended Leap 15.2 final release target. That Leap version is currently at RC stage as of a few days ago.

So if you fancy trying stuff out and reporting in as much detail as you can then it can only help. We are currently in the second release of what we are calling our beta stage of the Built on openSUSE testing channel:

BETA "Built on openSUSE" Testing Channel Changelog

3.9.2-59 Released 7th June 2020 Signing Key update required I am delighted to be releasing our second ‘Built on openSUSE’ beta rpm version. The main upset (we are in the testing channel here) as per the header, is that we have a new signing key. This one is my fault as I wanted to get this chicken/egg problem over and done with for the next keys duration (5 years) before we began our new Stable channel releases. All that is required is to re-run the prior rpm key import command introduced in …

as of 2 days ago.

@b8two

I do plan to change the OS drive when I get time,

Lets see some speed tests from that key, but remember the dd test will of course wipe it. But would be good to have an indicator of what speed it was actually capable of in comparison to the others tested there, and to compare it to the USB 2.0 max payload bandwidth of course. Will likely help for us to set our recommended minimum advised speed.

Hope that helps. And I apologise for not answering all of your questions but it may be that you attract others attention / knowledge in this area as we do have quite a few folks on the forum how are way more up on hardware than myself. I’m more jack of a few trades really and rely on contributions from specialists as we go along. But your point on the USB 2.0 limit is definitely an interesting one. Lets see your actual bandwidth results before we right off USB2.0 for the system disk as it’s still very common place on many machines. But we do run a full postgresql database (Django) for our Web-UI functions.