[[6.12.13] Unraid does format single-device pool as BTRFS, should be XFS]

On 8/29/2024 at 2:43 PM, itimpi said:

Stop the array and then click on the pool to set the format you want.   Restart the array and you will now be able to format it to the format you set,

 

Thanks worked.

 

[[6.12.13] NVMe no longer working]

17 hours ago, JorgeB said:

You usually need to power cycle the server to get the device back, just rebooting is not enough.

 

That's what I found out exactly. See above.

 

[[6.12.13] Unraid does format single-device pool as BTRFS, should be XFS]

16 hours ago, itimpi said:

If you click on the text for the setting you mention to activate the built-in GUI help it does make it clear that it applies to array devices and that pools always default to btrfs,

 

Why should an average user click on help if the text "Default file system format" is clear enough?

 

But the problem is: It's labeled wrong, at least misleading. IMHO this label should be changed to "Default file system format (arrays)" or something like this.

 

And if you consider a change. Why not add a second option "Default file system format (pools)" and preset it with btrfs?

 

That would it make clear for anyone.

 

[[6.12.13] Unraid does format single-device pool as BTRFS, should be XFS]

1 hour ago, JorgeB said:

the one in settings only applies to the array

 

Thanks. Please change the label (Default file system). It's confusing then.

 

1 hour ago, JorgeB said:

you can change the pool fs before formatting

Didn't find it. Where should I set it? The pool or the individual pool device? I'm pretty sure that I looked before trusting the default setting.

 

[[6.12.13] Unraid does format single-device pool as BTRFS, should be XFS]

33 minutes ago, itimpi said:

I think pools default to btrfs but you can change it to whatever file system you want and then do the format.

 

I double checked but could not find a way to set the file system of the pool. So I trusted the default setting (XFS).

 

Something must have changed during the years, because my old pool has XFS (see image below).

 

I suggest to change that wording - the label - to something more correct like "Default filesystem for array devices" !!!

 

 

Time for a third reboot to change that. BTRFS is no option here ... Look at that temperature. The XFS pool is in use. The BTRFS pool is used as backup once a day and not in use otherwise. It's sleeping currently.

 

[[6.12.13] NVMe no longer working]

With these settings in syslinux.cfg the second NVMe was missing completely. After removing this setting this NVMe is still not visible. Looking like an hardware error.

 

I remember these kinds of errors years ago. I could solve that with Shutdown/Restart instead of Reboot. Next time I will try Shutdown/Restart again.

 

***EDIT*** Couldn't wait. Did a complete shutdown and did restart with the Powerknob on the Supermicro case. Bingo. NVMe2 is back again. I must remember this. Never do a reboot on my system, shutdown the system completely instead.

 

[[6.12.13] NVMe no longer working]

15 hours ago, JorgeB said:

nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off

 

The interesting part is that this device was available after reboot for a short period of time. And after that it was gone silently. This combo was running happily for years with previous Unraid versions.

 

Is this correct?

 

 

I will reboot then and report.

 

Thanks.

 

[[6.12.13] NVMe no longer working]

1 hour ago, T0rqueWr3nch said:

Is that intentional?

Yes. I always wanted both NVMe as a 2-device pool. But I don't trust BTRFS and ZFS seems way to complicated to me. So I replicate the first pool device to the second one mounted thru Unassigned Devices via User Scripts. With multi-Array support - whenever it will arrive - I will change that to a 2-device Unraid array.

 

[[6.12.1] & [6.12.2] mc shows no progressbar]

I can confirm that for 6.12.10 in Unraid webterminal.

 

[USB stick is deleted when ZFS pool is created]

2 hours ago, ChatNoir said:

Please attach diagnostics when the problem happens.

 

Will diagnostics work without working Flash?

 

[[6.12.9] CIFS: VFS: directory entry name would overflow frame end of buf]

8 minutes ago, SteamedLobster said:

I think on a NAS anytime file sharing capabilities regress that's a major issue.

 

As I wrote - client mounts thru Unassigned Devices only AFAIK. Server/NAS shares work as usual AFAIK. The problem shows up if Unraid is the SMB client - not the server.

 

[[6.12.9] CIFS: VFS: directory entry name would overflow frame end of buf]

23 minutes ago, SteamedLobster said:

This seems to be a major regression.

 

I don't rate that as a "major" regression. If you don't use remote SMB/CIFS mounts you won't even notice it. It's a little niggle IMHO. Something that appears in special circumstances.

 

[[6.12.9] CIFS: VFS: directory entry name would overflow frame end of buf]

1 hour ago, SteamedLobster said:

Can't roll back as I didn't back up config

 

Just downgrade - no need to change config etc:

 

 

[[6.12.9] CIFS: VFS: directory entry name would overflow frame end of buf]

9 hours ago, dlandon said:

I am able to reproduce the issue.  It appears when you remote mount a share from a server that is not another Unraid.

 

In my case these were Unraid Servers running 6.12.9 as well. I did upgrade them all yesterday. All have SMB mounts to each others disks (disk shares) via Unassigned Devices.

 

They all showed this error. The mounts were there, but showed only the first directory per mount. syslog was full of CIFS VFS errors.

 

After downgrading all machines to 6.12.8 business is back as usual.

 

[[6.12.9] Since update UD always shows just one folder - the first one]

39 minutes ago, JorgeB said:

That should be reported in the UD plugin support thread.

 

I'm quiet sure that this is releated to this bug linked below. syslog shows system errors, the result is Unassigned Devices not working properly IMHO.

 

 

[[6.12.9] CIFS: VFS: directory entry name would overflow frame end of buf]

7 minutes ago, dlandon said:

Someone post diagnostics when this occurs so I can investigate further.

 

Did post diagnostics in my bug report:

 

 

[[6.12.9] CIFS: VFS: directory entry name would overflow frame end of buf]

Confirmed. Back to 6.12.8 as well.

 

[[6.12.4/5/6] Major GUI delays after upgrade (specially dashboard, docker and apps tab)]

49 minutes ago, CiscoCoreX said:

Two very different hardware here.

 

Just try with these two settings reversed and MACVLAN. Worst that can happen is a crash within 24 hours. That would mean you are affected by MACVLAN crashes. AFAIK this is a docker problem. I am through with this and have to live with 10-15 sec delay currently.

 

[[6.12.4/5/6] Major GUI delays after upgrade (specially dashboard, docker and apps tab)]

On 9/11/2023 at 8:45 PM, CiscoCoreX said:

Settings > Network Settings > eth0 > Enable Bridging = No

Docker settings, nSettings > Docker > Host access to custom networks = Enabled

 

These two are the problem. This workaround was recommended in 6.12.x for users experiencing "MACVLAN" crashes. You don't need them if you are a.) on IPVLAN or b.) didn't experience MACVLAN crashes or c.) you are no user of routers like Fritzbox in Europe.

 

[[6.12.4/5/6] Major GUI delays after upgrade (specially dashboard, docker and apps tab)]

12 hours ago, CiscoCoreX said:

Settings > Network Settings > eth0 > Enable Bonding = Yes

Settings > Network Settings > eth0 > Enable Bridging = No

Docker settings, nSettings > Docker > Host access to custom networks = Enabled

 

Ah, did these changes as well on 6.12.4 and have to wait approx. 10 sec most of the time - but not always. Sometimes even Login window needs 10 sec before it appears.

 

[[6.12.4] update_cron does not run during system start]

26 minutes ago, ljm42 said:

update_cron is called by Unraid to enable `mover`, but User Shares are disabled on this server so `mover` is not needed.

 

No User Shares, no Mover - it worked on 6.11.5, it stopped working with 6.12.4. This is a breaking change for e.g. plugins that rely on update_cron to add own schedules to cron.

 

I will call update_cron as a User Script within User Scripts plugin to work around this change. No big deal for me, but be prepared for plugins or users that stumble over this change.

 

BTW, why not call update_cron during system start always, just in case somebody needs it.

 

[[6.12.4] update_cron does not run during system start]

25 minutes ago, itimpi said:

Perhaps many people will not need the workaround anyway if they have a plugin (such as my Parity Check Tuning plugin) that issues this as part of its install process as the update_cron command is not plugin specific - it should pick up all cron jobs that any plugin has waiting to be activated.

 

I wrote @Squid in his User Scripts thread about our conversation here. Perhaps you both can talk about that (call update-cron during plugin installation).

 

I only have 4 plugins installed on these machines, only what's really required on these. None of my plugins - except User Scripts - has to set schedules. And I don't want to install a plugin I don't need except for calling update_cron  So I thiink it's up to this plugin to fix that. And if 6.13 will be picky during startup I think it's even more important to address that.

 

[[6.12.4] update_cron does not run during system start]

47 minutes ago, itimpi said:

There is also the possibility of a plugin that wants cron entries to be added to run this as part of installing the plugin (I know I do this for the Parity Check Tuning plugin).

 

I can add update_cron as a user script (that's fired during array start) to the User Scripts plugin. This would be a workaround.

 

[Unraid OS version 6.12.4-rc18 available]

1 hour ago, bonienl said:

Apply the changes AFTER updating

 

@ich777 asked me to add the following to my question above:

 

I'm running three Unraid server: One Unraid server running on bare metal and two Unraid server as VMs on that bare metal server. These two VMs act as DAS (Direct Attached Storage, access thru SMB) only - just the Array. No Docker Containers, no VMs.

 

His idea is that bridging needs to be enabled on the Unraid VMs - it is currently already.

 

Currently:

 

Unraid Bare metal: Bonding=no, Bridging=yes, br0 member=eth0, VLANs=no

Unraid VMs: Bonding=yes (active_backup(1)), Bridging=yes, VLANs=no

 

Docker Bare metal: MACVLAN, Host access=no

Docker on VMs: Disabled

 

Is this ok? It's running happily since years, currently on Unraid 6.11.5 with Fritzbox DSL IPv4-only.

 

[Unraid OS version 6.12.4-rc18 available]

Quote

Settings -> Network Settings -> eth0 -> Enable Bridging = No

Settings -> Docker -> Host access to custom networks = Enabled

 

Is it recommended to make these changes in 6.11.5 before the update from 6.11.5 to 6.12.4-rc18? Or should I update to 6.12.4-rc18 first and apply these changes afterwards?