schnapps issueshttps://gitlab.nic.cz/turris/schnapps/-/issues2023-08-16T14:00:34+02:00https://gitlab.nic.cz/turris/schnapps/-/issues/52schnapps -d /srv with zstd compression leads to periodical load average of 30+2023-08-16T14:00:34+02:00Orest Worhaczschnapps -d /srv with zstd compression leads to periodical load average of 30+Hi,
I am using msata drive formatted with Storage Plugin and I have chosen in Luci to mount it with:
```
/dev/sda2 on /srv type btrfs (rw,noatime,nodiratime,compress=zstd,ssd,space_c
ache,subvolid=743,subvol=/@)
```
While it was working...Hi,
I am using msata drive formatted with Storage Plugin and I have chosen in Luci to mount it with:
```
/dev/sda2 on /srv type btrfs (rw,noatime,nodiratime,compress=zstd,ssd,space_c
ache,subvolid=743,subvol=/@)
```
While it was working it was working but I think that using schnapps on such a system leads to load average range 30+ in some cases and the system becomes totally unresponsive. Cannot even login via ssh.
I was wondering that its acctually doing something so I let it be that much loaded and at some point it went down to load average 5+ and I could login and see htop and netdata and the cpu was at 50% and according to netdata it was used by 'system'. But later on it went back to unresponsive state and dropped ssh connection.
I had this problem before as it lead me to invalid snapshots half-made as the router just hang in the middle of creating a snapshot. So I taken out the drive connected it via adapter to my laptop. Deleted all btrfs subvolumes except @ and recompressed all files with btrfs defrag and connected it back and it was all again around 1-4% cpu usage.
Before I also tested that taking out the drive from Omnia also fixed this extreme load. With the drive unresponsive, without just fine.
So I request to test schnapps with btrfs compressed drives as all problems begin when I try to do some schnapps operation like creating or deleting the snapshot.
Thanks!Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/44SMB1 mounts are not supported2021-10-20T09:34:48+02:00Michal VasilekSMB1 mounts are not supportedTrying to mount a Synology NAS, I get this error:
```
mount error(95): Not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Can't access remote filesystem
root@omnia:~# dmesg
...
[ 56...Trying to mount a Synology NAS, I get this error:
```
mount error(95): Not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Can't access remote filesystem
root@omnia:~# dmesg
...
[ 5686.349245] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
```
Adding `-o vers=1.0` to the mount.cifs command fixes this issue for me. I think the defaults are correct now, maybe adding an option (with a warning) to use the 1.0 version or documenting this would make life easier for some people. If this is the default behavior of some (?) older (?) Synology NASes, this issue would be common.
Either way, I think this message in dmesg is logged even when the server supports SMB3, so it should probably be silenced with `-o vers=default`.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/39Allow import of medkits2021-06-21T11:10:10+02:00Karel KociAllow import of medkitsRight now the only way to import medkit is to import it as a factory. This is in most cases the correct way user wants to import medkit but sometimes it makes sense to want to import it just like the regular snapshot without having an in...Right now the only way to import medkit is to import it as a factory. This is in most cases the correct way user wants to import medkit but sometimes it makes sense to want to import it just like the regular snapshot without having an info file. I mostly use it when someone sends me the image to test some issue. I do not want to replace the factory image and I do want to remove it afterwards.
My suggestion is to allow import of generic medkit with switch `-m`:
```
schnapps import -m omnia-medkit-100.tar.gz
```
It would automatically fill in info for example as if following info file would be provided:
```
TYPE="single"
DESCRIPTION="Medkit: ${file%.tar.gz}"
CREATED="$(date)"
```Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/13[feature suggestion] Automatic sync on creating/modifying snapshots2019-11-18T16:53:36+01:00David Beitey[feature suggestion] Automatic sync on creating/modifying snapshotsWhen reading the documentation for sync (https://docs.turris.cz/geek/schnapps/schnapps/#remote-manipulation-with-snapshots), I got the impression from setting up a remote URL as part of the 'global' configuration that schnapps might auto...When reading the documentation for sync (https://docs.turris.cz/geek/schnapps/schnapps/#remote-manipulation-with-snapshots), I got the impression from setting up a remote URL as part of the 'global' configuration that schnapps might automatically keep things in sync when creating/modifying/deleting snapshots.
This isn't currently the case so it'd be great if there was an option to enable this -- or else made the default if a remote URL is configured. I feel this is a sensible default as it would help ensure remote snapshots are always up-to-date (particularly helpful in the case of backups).
I've set up `cron` to run `schnapps sync` periodically, but given the [schedule for schnapps](https://gitlab.labs.nic.cz/turris/schnapps/blob/master/schnapps.cron) it's fiddly trying to ensure calls to `sync` run at the right times.Michal HruseckyMichal Hrusecky