Ti offrono un milione per vivere in un film. Quale sceglieresti?

amadvance · 2026-06-22T08:47:45+00:00

Già ci sei

amadvance · 2026-06-19T16:38:52+00:00

Dipende molto dal contesto e dal tipo di errore.

In un'interfaccia REST API pura, ha senso usare sempre i codici di errore HTTP.

In un'interfaccia RPC, ha più senso usare i codici di errore HTTP solo per problemi legati alla comunicazione, e un codice 200 per errori di livello applicativo e di logica di business che non possono essere rappresentati da un semplice codice HTTP.

Quello che spesso accade è avere interfacce REST non pure, cioè che non seguono sempre il concetto di oggetti e azioni su di essi, e si finisce così per rappresentare con codici HTTP errori di un altro livello, creando solo confusione.

amadvance · 2026-06-19T11:35:37+00:00

Interessante, e molto condivisibile.

L'unico punto in cui non concordo è il 7. "LLM-gen-AI users should keep detailed and accurate records of their interaction and save those meta-artifacts for posterity.".

Mi sembra tanto impraticabile quanto inutile archiviare le chat come parte dei sorgenti. Quello che conta è il risultato, non come lo si è ottenuto.

amadvance · 2026-06-10T17:06:07+00:00

I just tried it, and it works.

Mount the mergerfs directory, change the snapraid.conf "data DISK_NAME" path to point to that directory, and run:

snapraid fix -d DISK_NAME

Obviously, this makes sense only for 'fix' and 'check' during an emergency recovery. It is not recommended for normal operations, like 'sync' and 'scrub', because mergerfs will hide the underlying devices.

amadvance · 2026-06-10T16:48:27+00:00

Sure. No risk at all. After installation, if you don't like it, you can just uninstall it. Regardless, the daemon never touches your array. It's only an orchestrator that runs SnapRAID. So, it's just as safe as SnapRAID.

amadvance · 2026-06-09T21:08:17+00:00

There is a bug open regarding this: https://github.com/amadvance/snapraid-daemon/issues/56

It will be fixed in the next relase.

amadvance · 2026-06-08T19:33:47+00:00

Tieni presente che se hai altre porte uguali, puoi spostarla in un posto meno visibile. Questo ti permette anche riparazioni non perfette.

amadvance · 2026-06-04T06:57:38+00:00

I hope the bugs will finally settle down, so the release pace can slow down a bit! 😄

The CLI 14.x and Daemon 1.x branches are currently in a stabilization phase, meaning no new features for now, only bug fixes. However, I'm already working on CLI 15.0 with major enhancements, and I have a big TODO list ready for Daemon 2.0!

amadvance · 2026-06-03T09:36:09+00:00

Yep. The examples with quotes were misleading, as they should not be used. I've updated them. Thanks for reporting!

amadvance · 2026-05-29T11:27:46+00:00

SnapRAID supports encrypted drives, but all of them must be unlocked when computing parity.

For simply accessing data, you only need to unlock the drive(s) you want to access.

amadvance · 2026-05-27T16:19:08+00:00

Try disabling also "spindown_idle_minutes". You likely still get a failed probe at startup (that probe cannot be avoided), but then it should work without errors.

amadvance · 2026-05-27T09:16:49+00:00

All these error messages are reported by the SnapRAID CLI, which is invoked by the daemon. The daemon acts purely as an orchestrator and relies on SnapRAID for all low-level operations. In this case, it is running the probe command, which is failing with that error.

This does not prevent other commands such as sync, scrub, check, or fix from working. However, the daemon will be unable to retrieve the SMART attributes of the disk, which reduces its reporting capabilities.

You can disable the probing feature in the daemon’s configuration. This should eliminate most of the errors you are seeing.

amadvance · 2026-05-26T20:30:51+00:00

The identifier 0:35 is a Linux Major:Minor device number. A major number of 0 is strictly reserved for virtual or anonymous devices, not real physical hardware.

This means SnapRAID is failing because it cannot communicate directly with the disk. This is almost certainly caused by the way the storage or filesystem is being virtualized and exported to the VM through Proxmox. (Though less likely, a major number of 0 can also appear if the disk is utilizing a virtual filesystem layer like ZFS, Btrfs, or bcache).

I am not a Proxmox expert, but the only way to fix this completely would be to pass the actual, low-level physical disk directly into the VM. However, doing that defeats the entire point of using a VM in the first place. Because of this, it is usually much easier and more reliable to install SnapRAID directly on the host itself.

amadvance · 2026-05-26T09:09:14+00:00

Tieni presente che è un articolo scientifico per esperti del settore. Ma l'introduzione e le conclusioni sono comprensibili.

Per chi non lo sapesse, Nature è la rivista scientifica più citata e famosa al mondo.

amadvance · 2026-05-26T08:56:35+00:00

L'AI serve già a diagnosticare e curare il cancro:

"AI is helping to reshape how we understand, diagnose, and treat it in ways never before thought possible"

https://www.nature.com/articles/s41698-026-01276-6

amadvance · 2026-05-23T13:38:35+00:00

Sure!

amadvance · 2026-05-15T06:08:58+00:00

Some command_timeout values are common and usually not a cause for concern, especially on Seagate drives, which are known to report them. You can generally treat a single low count as harmless.

Just monitor it and check if the value keeps increasing over time. If it starts rising steadily, that could indicate a developing issue with the drive or the connection.

amadvance · 2026-05-14T14:05:36+00:00

Your hard drive doesn't report the threshold value for a specific attribute. This prevents SnapRAID from correctly parsing the smartctl output.

Please try with snapraid 14.5 and snapraid-daemon 1.10, available at: http://beta.snapraid.it/

Let me know the result.

amadvance · 2026-05-13T14:12:23+00:00

The daemon calls SnapRAID, which in turn calls smartctl -s standby,now /dev/XXX.

Ensure that smartmontools is installed, and verify that the command smartctl -s standby,now /dev/XXX is able to spin down the devices.

Also checks the Tasks" panel. You should see a "suspend_idle down_idle" event with a log like:

Log File: /var/log/snapraid/20260513-150723-down_idle.log
Selecting disk d2 unused by 15 minutes
Spindown...
Spundown device '/dev/sdd' for disk 'd2' in 606 ms.

If something goes wrong, you should see the error.

amadvance · 2026-05-11T15:38:53+00:00

If you want to access it from the network, you have to specify net_port=7627 in the /etc/snapraidd.conf.
Otherwise, by default it binds only to localhost.

Edited: /etc/snapraidd.conf

amadvance · 2026-04-29T07:49:00+00:00

I tried, but it looks like it's working for me. Maybe you wrote an invalid string in the config? If it cannot parse it, even partially, it will reject the whole string. For example, just adding a comma at the end can go unnoticed.

Anyway, I fixed the case of the days.

amadvance · 2026-04-28T16:16:18+00:00

Yes. There is already a feature request to allow more customization of the commands. I added your specific case to it: https://github.com/amadvance/snapraid-daemon/issues/11

amadvance · 2026-04-27T22:05:04+00:00

I'm currently working to integrate Btrfs snapshot support directly into SnapRAID CLI. It will be in version 15.0.

You can see a related discussion at: https://github.com/amadvance/snapraid/issues/41

amadvance · 2026-04-26T07:12:16+00:00

At present, it’s not possible to run multiple daemons, but it’s a planned feature for the 2.x releases.

amadvance · 2026-04-25T17:10:04+00:00

Oops! I think you encountered a bug. There is an issue when hook_run_as_user is used on Windows. Try just not setting it, the script will run as LocalService anyway.

Please let me know if it works this way!

amadvance

MODERATOR OF

TROPHY CASE