[[6.9.0-beta35]failed to auto start array when network disconnected]

It looks like you are running a trial license and one of the requirements of the trial licence is that you have an active internet connection before the array can be started.

[Very slow download speeds of USB Flash Creator image]

There have been occasional reports of slow speeds but the vast majority of people do not see this and get very fast speeds.    Suggests it could be something in the network link between you and the Amazon servers that is limiting the speed.

[[6.9.0 betas & 6.9.1] Apcupsd issue when booting]

Not sure how easy it is to simulate the physical unplug/plug of USB in software.   Are you saying that stopping the USB daemon; waiting a short while for the USB to reset; and then restarting the USB daemon is not sufficient?  Feels much simpler than trying to emulate a USB unplug/plug sequence

[Very slow download speeds of USB Flash Creator image]

The files are actually stored on the Amazon AWS servers, not on the Unraid web site so any speed issues are there.

[[6.9.0 - Beta 30] Moving a file on the cache to a share with cache off keeps it on there forever]

Yes, you need to use copy/delete if you want the file to end up on a different drive.    It is a quirk of the Linux implementation of the ‘mv’ where if source and target appear to be on the same mount point (/mnt/user) a rename is issued (which leaves the file on the same drive) rather than a copy/delete action.

[[6.9.0 - Beta 30] Moving a file on the cache to a share with cache off keeps it on there forever]

This is intended behaviour.    There are some Use Cases that exploit this behavior.

[[6.8.3] - NGINX - Out of shared memory]

6 hours ago, Struck said:

The problem seemed to be unmounting disk shares, of which i have none i think

It would have been unmounting disk drives (not shares) which is a standard step in stopping the array.

 

[WebUI on iOS - No Zoom / Scroll]

1 hour ago, yyc321 said:

Firefox appears to behave the same as safari and chrome on iOS.   

I think that Apple mandates that all browsers on iOS use their rendering engine, so this is probably an issue (bug?) at that level.

[[6.8.3.] New Config resets Disk Shares Security Settings]

2 hours ago, trurl said:

Even if you retain all you can still make any changes including changing slots so some default settings is probably the only thing that makes sense. 

Not sure I agree here.   Changing slots still does not necessarily mean you want the shares to be set up any differently.  
 

Perhaps the best way forward would be to add a new check box to the New Config dialog as to whether shares settings should be left unchanged or reset to defaults?    At least that would give visibility to the effect that share settings might be affected.   Making the default the current behaviour would mean users only get the share settings retained if they explicitly ask for them.

 

do you think this should explicitly be raised as a feature request?

[[6.8.3.] New Config resets Disk Shares Security Settings]

I suspect that technically this is not a bug in that the New Config is working as designed.

 

Having said that I agree it might make a lot of sense to leave all share settings unchanged when usin New Config - especially if using the option to retain current disk assignments.   I personally would find that more convenient than current behaviour.
 

I do not like your second option as that would cause problems for users who have their shares exported and set to Public.

[Unraid OS version 6.9.0-beta30 available]

Do you have any docker containers that if you look at the Docker tab and switch on the Advanced view show they are ‘healthy’?    It has been noticed that such containers have been set up by their authors to write to the docker image every few seconds as part of a health check, and although the writes are small the write amplification inherent in using BTRFS means this can add up.   I believe that an issue has been raised against docker in case this is a bug in the Docker engine rather than the container authors simply mis-using the health check capability.

 

In addition there are other options available in the Docker settings that can reduce this load such as using an XFS formatted image instead of BTRFS, or not using an image at all and storing directly into the file system.  The array has to be stopped to see these options.    Have you tried any of these?

[Unraid OS version 6.9.0-beta30 available]

9 hours ago, jdiggity81 said:

I take it that means with the work around you built in that the lsi 9200-16e will work until they make the corrections?

Strange that the 'e' model needs this whereas the 'i' model (which I have) does not.   You would have thought they would be identical except for the connector being external rather than internal.

[[6.8.3] Unnecessary overwriting of JSON-files in docker.img every 5 seconds]

6 minutes ago, mgutt said:

Besides of that. Are these JSON files really part of an usual docker installation or is this a special Unraid thing? I wonder why only Unraid users are complaining those permanent writes. Ok... maybe it has the most transparent traffic monitoring

 

This is nothing to do with Unraid - it is internal to the docker container.   It may have been more obvious to Unraid users because of the fact that a docker image is used and there was an issue in 6.8.3 and earlier that could cause significant write amplification when writing to that image stored on a SSD.   If the docker container files were stored directly in the file system (as the latest Unraid betas allow) then this is probably far less noticeable particularly if using a HDD with a file system like XFS that has far less inherent write amplification than BTRFS does.

 

11 minutes ago, mgutt said:

If these writes are related to Docker only, we should open an issue here. Because only updating a timestamp (or nothing) inside a config file, does not really sound like it's working as it meant to be.

This could not do any harm although they may simply reply that the feature is being mis-used and the fix should come from the container maintainer.

 

[[6.8.3] Unnecessary overwriting of JSON-files in docker.img every 5 seconds]

Not obvious on the best way to handle this as technically this is an issue with specific docker containers rather than an UnRAID issue.   There may be good reasons the maintainer of a particular container has set this up so that over-riding it becomes a bad idea.    I wonder if the Fix Common Problems plugin could be enhanced to detect this and suggest the fix?  Alternatively make it a configuration option in the docker templates?

[[6.9.0 Beta 29] whole cache drive is public]

What do you have for the Disk Shares option under Settings->Global Share Settings (if you had posted the system's diagnostics zip file I could have seen for myself).

 

If you click on the Shares tab does it show the cache under the Disk Shares?   If so you should be able to set the security level from there.   However whether it should be showing up under the Disk Shares section by default becomes an interesting question.

[Unraid OS version 6.9.0-beta25 available]

4 minutes ago, jowi said:

Depends on how many dockers you have listed. If they don’t fit the screen, the interface gets stuck. It won’t scroll. Display font size also plays a role, the bigger the font, the less dockers you can list, and the gui gets stuck and wont scroll.

 

But then again, this is not specific for this version, its an issue for as long as there are dockers in unraid. It wont get fixed for some reason.

 

I have far more Dockers than fit on the screen and they scroll OK for me on my iPad.

 

i think the root cause has to be some sort of bug at the web kit level which can therefore affect all iOS/iPadOS browsers as Apple mandates they have to use WebKit for rendering.  I would be interested to know if anyone using Safari on MacOS ever experience such problems.

[Remote syslog server port field too short]

I would assume this means the 6.9.0 beta25 release.

[Unraid OS version 6.9.0-beta25 available]

12 minutes ago, MothyTim said:

It's only the docker page, everything else is fine! It's the same in Safari and Chrome.

As i said it is working fine for me.   I have had problems in the past but it is OK now.   It may be relevant that I am using the iOS14 beta so possibly a web engine (Which is used by both those browsers)  problem has been fixed.

[Unraid OS version 6.9.0-beta25 available]

I have no problem using the Unraid interface on my iPad.

[Unraid OS version 6.9.0-beta25 available]

30 minutes ago, Dephcon said:

 

That's very interesting.  Say or example I have a share that's 'cache only' and i change which pool device i want it to use, unraid will move the data from one pool device to the other?  That would be highly useful for me in my IO testing.

No, Unraid will not move the data to the new pool.      It will just start using that pool for any new files belonging to the share.      Note that for read purposes ALL drives are checked for file under a rip level folder named for the share (and thus logically belongs to the share).   The files on the previous pool will therefore still be visible under that share even though all new files are going to the new share.

[Unraid OS version 6.9.0-beta25 available]

Actually thinking about it where can one now set the Minimum Free Space value for a cache pool?   It used to be on the 

global settings.   The setting on the Shares tab applies I thought to array disks?

[Unraid OS version 6.9.0-beta25 available]

1 hour ago, bubbl3 said:

I have it enabled there for appdata, then why the mover doesn't it enabled? also, how does one move all the existing data to the cache drive without the mover? Hopefully not manually...

If you want mover to move files from array to cache then the Use Cache setting needs to be set to Prefer.   The GUI built-in help describes how the various settings affect mover. Also mover will not move any files that are open so you may need to disable the docker and/or VM services while such a move is in progress.

[Vfio in system devices not passing through Graphics card]

How are you trying to access the web interface?   You would thot be able to do it on a directly attached monitor if you have used the vfio method to stop Unraid from using that monitor for its own purposes, but you should still be able to access the GUI via  the network.

[[6.8.3] docker image huge amount of unnecessary writes on cache]

12 hours ago, Lignumaqua said:

The link below is to an interesting paper from 2017 that compares the write amplification of different file systems. BTRFS is by far the worst with a factor of 32x for small files overwrite and append when COW is enabled. With COW disabled this dropped to 18.6X, which is still pretty significant. This is three years ago, so things may have changed. In particular space_cache V2 could be  a reaction to this? BTRFS + writing or amending small files = very high write amplification.

 

https://arxiv.org/abs/1707.08514

This suggests that BTRFS is a great system for secure storage of data files, but not necessarily a good choice for writing multiple small temporary files, or for log files that are continually being amended.  Looking at common uses of the cache in Unraid might lead to the following suppositions. A BTRFS cache using Raid 1 is a good place for downloaded files before they are moved into the array. It's also good for any static data files. However, it's likely not to be the best place for a Docker img file or any kind of temporary storage. Particularly if redundant storage isn't needed. XFS might be a better choice there.

I found this research article to be of great interest as it indicates that a large amount of write amplification is inherent in using the BTRFS file system.

 

I guess this raises a few questions worth thinking about:

• Is there a specific advantage to having the docker image file formatted internally as BTRFS or could an alternative such as XFS help reduce the write amplification without any noticeable change in capabilities.
• This amplification is not specific to SSD's.
• The amplification is worse for small files (as are typically found in appdata share).
• Are there any BTRFS settings that can be applied at the folder level to reduce write amplification.  I am thinking here of the 'system' and 'appdata' folders.
• If you have the CA Backup plugin to provide periodic automated backup of the appdata folder is it worth having that share on a single drive pool formatted as XFS to keep amplification to a minimum.  The 6.9.0 support for multiple cache pools will help if you need to segregate by file format.

 

[xfs_repair typo]

That is a standard Linux utility, not something Limetech are involved in producing.

 

The bit you highlight is not a typo.    It is standard Linux-speak telling you to use the Linux built-in ‘man’ command (which gives details of any Linux command) to get more detail on the options.