If I run `zfs list`, I see that some dataset mountpoints are listed as "legacy", which means that other tools (not ZFS) will take care of mounting these. Which code/script mounts/can mount these? In this particular case I am referring to .system datasets. I have more than one (probably due to upgrades over the years) and I want to remove the non-current ones but want to check that no other code/scripts have a reference to the old ones marked "legacy".
-
Important Announcement for the TrueNAS Community.
The TrueNAS Community has now been moved. This forum has become READ-ONLY for historical purposes. Please feel free to join us on the new TrueNAS Community Forums
where are "legacy" mounts handled
- Thread starter dlaflamme
- Start date
- Joined
- Nov 25, 2013
- Messages
- 7,776
You can type
df or mount to find the currently active ones.Thanks. Yes, I know that and in general the "legacy" ones that I think can be removed are not actively mounted. Right there I could probably feel pretty safe getting rid of them. However, anyone know the mechanism that TrueNAS does use to mount legacy ones? I don't see fstab entries for the active system dataset, for instance.
- Joined
- Nov 25, 2013
- Messages
- 7,776
Their startup scripts do it, reading the configuration from an SQLite database.
winnielinnie
MVP
- Joined
- Oct 22, 2019
- Messages
- 3,641
Are you referring to the child datasets under the .system dataset which are appended with a string of random numbers?
If so, you can follow this method to figure out which ones are "residual" and no longer being used, hence safe to delete:
Corrupt files; where?
It looks like this is a snapshot generated from an @update. That snapshot is not the main issue here, since as you can see... volume1/.system/syslog-097c772a7a1e40b5a1773cbed6329f54:/log/mdnsresponder.log ...this is not from a snapshot. It's on the live filesystem. So now I would be worried...
www.truenas.com
EDIT: Don't be fooled by the thread's title. The post I linked to directly is where a second discussion / approach begins for another issue outside of their main problem about data corruption.
Last edited:
That is what I thought as well. In fact, notes I have from 5+ years ago show there used to be a
storage_mountpoint table in the freenas-v1.db file. However, that doesn't appear to exist anymore. Further, if I dump the contents of that file as SQL statements and grep for mount, mnt, legacy, etc. I don't see anything. Perhaps the mechanism has changed.Are you referring to the child datasets under the .system dataset which are appended with a string of random numbers?
If so, you can follow this method to figure out which ones are "residual" and no longer being used, hence safe to delete:
Corrupt files; where?
It looks like this is a snapshot generated from an @update. That snapshot is not the main issue here, since as you can see... volume1/.system/syslog-097c772a7a1e40b5a1773cbed6329f54:/log/mdnsresponder.log ...this is not from a snapshot. It's on the live filesystem. So now I would be worried...
Thank you, there are some useful tidbits in that thread.
