trim/discard after reboot on cf-card leads to failure #2357
Comments
|
Hi Christian, Can you try to add "# notrim" to the root disk entry in /etc/fstab prior to the first reboot? Cheers, |
|
ufs doesn't seem to know the option 'notrim' |
|
no, at the end with a leading "#", it's a comment evaluated in our code: https://github.com/opnsense/core/blob/master/src/etc/rc#L81-L84 The trouble is that the driver seems to say trim is ok, when it in fact may be not :/ |
|
sorry, thought of a common fs option. Isn't that a bit unconventional ? Hmm, during the first boot I found in fact |
|
Nothing about enabling TRIM is conventional. :)
Maybe this is needed prior to first boot. Let me give you an image for that later today.
… On 13. Apr 2018, at 18:10, c-schwamborn ***@***.***> wrote:
sorry, thought of a common fs option. Isn't that a bit unconventional ?
Sadly it didn't work:
Mounting filesystems...
tunefs: soft updates remains unchanged as enabled
tunefs: file system reloaded
tunefs: issue TRIM to the disk cleared
tunefs: file system reloaded
** /dev/ufs/OPNsense_Nano
FILE SYSTEM CLEAN; SKIPPING CHECKS
clean, 3158490 free (1234 frags, 394657 blocks, 0.0% fragmentation)
** /dev/ufs/OPNsense_Nano
FILE SYSTEM CLEAN; SKIPPING CHECKS
clean, 3158490 free (1234 frags, 394657 blocks, 0.0% fragmentation)
uhub0: 4 ports with 4 removable, self powered
(ada0:ata0:0:0:0): DSM TRIM. ACB: 06 01 00 00 00 40 00 00 00 00 01 00
(ada0:ata0:0:0:0): CAM status: Command timeout
(ada0:ata0:0:0:0): Retrying command
ada0 at ata0 bus 0 scbus0 target 0 lun 0
ada0: <SanDisk SDCFH-004G HDX 5.11> s/n CLZ101210182346 detached
Hmm, during the first boot I found in fact tunefs: issue TRIM to the disk set
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Stupid question: Why is trim/discard enabled on those images anyways? I thought they where only for legacy devices like these alix boards. To my knowledge it's not possible to use discard or trim on cf- or sd-cards, or do you intend these images for some sort of vm usage on ssd's or thin lvm? |
don't tell me about that, I read the ssd feature exclude list in the linux kernel code
You don't have to create an image just for me, do it only if it helps to fix the issue for future images. |
|
I use an APU 1 board with a SD card without issues with trim. Maybe the problem is vendor specific. |
It's a good question. I think this was done unilaterally on all images while we were on FreeBSD 10 almost exactly 2 years back (44b610a), but FreeBSD 11 changed the game somehow, causing these reboot-fail issues for very specific cases. @fabianfrz is right, I also have APUs/ALIX/WRAP and never seen the issue, otherwise I would have been able to inspect it. We've tried almost everything here to help since early 2017 (FreeBSD 11 with OPNsense 17.1) but nothing seemed to help. It could be that this was missed all along. At least I know we never looked for this specifically. Here is an image based on 18.1.6. It's quite important to try it, because we are about to release images and if this helps I'm willing to add it last minute: https://pkg.opnsense.org/FreeBSD:11:i386/snapshots/OPNsense-18.1.6-notrim-OpenSSL-nano-i386.img.bz2 Thank you, |
|
loading the image now. to be specific on the hardware: I tested this on three different alix.2d13 boards with two cf-cards both sandisk ultra (a 4GB and a 8GB card). My guess is that not trim on principal is the issue here, but the underlying drive deciding which device is capable to perform trim/discards. I think sd-cards are similar to usb sticks where as cf-cards are connected to the old ide/ata interface, at least on those old alix boards. |
|
Good news: That worked. What did you change, if I may ask? I've seen the rootfs in |
|
It‘s static for this one, embedded on image build so TRIM is never forced on the disk during first boot. The funny thing here is that the device says TRIM is ok, so that’s when it’s being enabled... Maybe something changed here WRT FreeBSD 10 -> 11. it looks more and more like it.
Since this works I’ll fix up the nano images for 18.1.6 and then when 18.7 is here we can reassess this situation. But I would say not having TRIM here by default seems like the safer option anyway.
Sounds good? :)
Thanks,
Franco
… On 14. Apr 2018, at 14:39, c-schwamborn ***@***.***> wrote:
Good news: That worked.
I think the line you where looking for is tunefs: issue TRIM to the disk remains unchanged as disabled.
What did you change, if I may ask? I've seen the rootfs in /etc/fstab now contains # notrim at the end by default. Is that static, or somehow dynamically added?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Yes, sounds good. For the time being this might be the safest way to go. |
|
Okay, commit via opnsense/tools@2fb26bf Again, thanks for the help! Cheers, |
|
Thank you, for your quick response. Cheers, |
|
I am seeing this again after upgraded to 20.1.3. In fact I have trouble upgrading to it completely it seems. I installed from usb stick a view days ago and upgraded to 20.1.2 on the gui without any incidence, but now I am seeing strange effects after I did an upgrade to 20.1.3 and the console is throwing alot of ata trim errors (for the first time here). I tried adding the # no trim option as described to my fstab to no avail. My changes in settings are not persistent through reboots any longer (like enabling ssh). Its gone after a reboot. |
I just tested a fresh install (v.18.1) via nano bsd i386 image on an pcengines alix system with cf-card. The first boot looks fine, but after the first reboot the system doesn't boot anymore. Investigating the issue, the last console entry revealed, that a trim command was issued to the filesystem, leading to a disconnect of the cf-card:
clean, 7046762 free (1226 frags, 880692 blocks, 0.0% fragmentation) (ada0:ata0:0:0:0): DSM TRIM. ACB: 06 01 00 00 00 40 00 00 00 00 01 00 (ada0:ata0:0:0:0): CAM status: Command timeout (ada0:ata0:0:0:0): Retrying command ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: <SanDisk SDCFHSNJC-008G HDX 7.08> s/n BMZ080115030144 detached g_vfs_done():ufs/OPNsense_Nano[WRITE(offset=2932998144, length=8192)]error = 6 g_vfs_done():ufs/OPNsense_Nano[WRITE(offset=2990456832, length=8192)]error = 6 g_vfs_done():ufs/OPNsense_Nano[WRITE(offset=3047964672, length=8192)]error = 6 g_vfs_done():ufs/OPNsense_Nano[WRITE(offset=3278061568, length=3072)]error = 6 g_vfs_done():ufs/OPNsense_Nano[WRITE(offset=5865824256, length=8192)]error = 6 g_vfs_done():ufs/OPNsense_Nano[WRITE(offset=5865832448, length=8192)]error = 6 g_vfs_done():ufs/OPNsense_Nano[WRITE(offset=8192, length=2048)]error = 6 g_vfs_done():ufs/OPNsense_Nano[WRITE(offset=32768, length=8192)]error = 6 g_vfs_done():ufs/OPNsense_Nano[READ(offset=9027584, length=4096)]error = 6 g_vfs_done():ufs/OPNsense_Nano[WRITE(offset=1897799680, length=8192)]error = 6 g_vfs_done():ufs/OPNsense_Nano[WRITE(offset=2875449344, length=8192)]error = 6 (ada0:ata0:0:0:0): Periph destroyed /usr/local/etc/rc: /usr/local/etc/rc.subr.d/recover: Device not configured /usr/local/etc/rc: /etc/rc.d/syscons: Device not configured /usr/local/etc/rc: /usr/local/etc/rc.importer: Device not configured /usr/local/etc/rc: /sbin/consco: not found vm_fault: pager read error, pid 1 (init) vnode_pager_generic_getpages_done: I/O read error 5The last two lines repeat indefinitely.
After successfully booting the system in save mode, I disabled trim with tunefs for the root filesystem and after that, the system booted normal.
Maybe the resizing to the medium size leads to an enabling of the filesystems trim/discard option.
cheers
Christian
The text was updated successfully, but these errors were encountered: