b0fh

@George - That is not ARM software. That is Intel.

I am finding some information that indicates the LSI card may not like the Samsung 850 EVO drives and thus does not enable SSD trim functionality. I was using another controller card prior to 6.1, I had forgotten that. So, basically, I think I am SOL.

I have a DSM 6.1.5 running on a LSI 9207-8i controller with 8 Samsung EVO 250gb SATA drives. The raid group is a RAID10. I have also tested with a single disk basic volume as well.I cannot see the tab that allows SSD trim to be enabled. I was running in RAID6 prior, but rebuilt in RAID10. I know the option was not allowed in RAID6, but I know it *used* to be configurable and could be enabled in DSM 5.2. I upgraded from 5.2 to 6.1, so I do not know when it might have broken. Does anyone else have a different experience? What might I be missing? *edit* Forgot to mention I am using the ds3615xs firmware if that matters.

It is ultimately up to you, but BTRFS is working out pretty well so far.

RO = read only - i was not able to delete snapshots to free up space. PITA - pain in the a$$, I ended up deleting my volume and starting over from a last known good.

I used BTRFS because it enabled some features I wanted to test. Be aware, snapshots will take extra space, though, and if you fill up your drive with snapshots, it will be marked RO and will be a PITA to recover from. I also have a complete backup as well, just in case.

You don't really want an SSD tied to an ATAPI or IDE mode port, performance will not be very good if it works at all. I would buy a cheap sata controller instead. Check these forums, there have been a few posts.

I am only guessing, but I suspect that port may be set (or only allowed to be changed from) ATAPI mode instead of AHCI mode. If it can be changed, it should be addressable in the BIOS.

From (hxxps://www.v-front.de/2013/11/how-to-make-your-unsupported-sata-ahci.html): There is a bug in the firmware of some Marvell adapters (at least 88SE91xx) that prevents it from properly detecting attached devices if you have VT-D enabled in your computer's BIOS. As a workaround disable VT-D! (see this bug report. Many thanks to Adalbert for finding this out!).

By chipset, I mean the SATA card, just so there is not some confusion.

I believe that exact chipset is not PCI passthrough compatible. It never shows up in a guest. I fought this issue for a couple of hours before finding a post on it somewhere. Try a different chipset/sata card.

It might, but if it is not being used much, as most of our N54Ls are not I suspect from a processor perspective, the fluctuation may be more harmful that it is worth. And for battery operated devices like the phones mentioned above, it matters. For devices on power all the time, if a processor is idling at 2.0ghz or 800mhz, the actual power used is minimally different. I am not trying to be an a$$, just pointing out that often things are just not worth chasing. I know I had to disable C1E on my n54l when moving from 5.2 to 6.1, and that disabled some of the more effective power savings anyway. But again, n54l is pretty cheap to run 24x7x365 as it is.

Has anyone actually measured any appreciable power usage difference before and after running this script? Your CPU is not running 100% just because your CPU it showing full speed. I imagine the difference with CPU stepping on vs off for most people is tens of pennies per year, honestly.

Baremetal N54L, random Athlon Phenom II hardware, random Intel E6850 hardware, and ESXi guest all upgraded just fine and seem to be humming along.

No. You need to disable transport mode encryption. Synology has confirmed that is the proper workaround at this time.

And do you have SHR enabled in synoinfo.conf? It will certainly "import" existing SHR volumes, but I am not sure you can make any changes without it enabled.

One additional note, my system is reporting <4gb ram available but has 8gb in it. It reported all 8gb before the upgrade, but is now only reporting something like 3.5gb, like it defaulted back to x86 from x64, but it is still showing x86_64 in the kernel (uname -a). No biggie as I am hoping to retire this server soon (move to a VM), but thought I would report it. Sorry for spamming up the thread.

Ok, so the issue was C1E. I could have sworn I had disabled it, but I must have exited BIOS without saving. It is working fine so far after the upgrade (and it was pretty painless from there on out).

I missed the part about the MBR bootloader. I'll try that. Machine is older to be sure.

I have searched but come up empty. I am using an Intel dual port NIC that uses the e1000e driver successfully in a bare metal 5.2 install. I tried to use the 1.02b loader from mega that was posted here and it does not load the NIC drivers. Here is what lspci -v shows regarding in 5.2: 02:00.1 Class 0200: Device 8086:105e (rev 06) Subsystem: Device 8086:115e Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at fea80000 (32-bit, non-prefetchable) Memory at fea60000 (32-bit, non-prefetchable) I/O ports at e880 Expansion ROM at fea40000 [disabled] Capabilities: [c8] Power Management version 2 Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [e0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 00-15-17-ff-ff-c5-ad-1a Kernel driver in use: e1000e When I try to boot on 1.02b, it looks normal, but I cannot find the NAS with utilities and it is not pulling a DHCP address. Do I need to explicitly call the extras? It looks like it should work on its own. Sorry to have to ask.

What bootloader are you using?

No, it must be a volume. You can use the USB to transfer apps for backup or while moving, but its easiest to just have a separate volume for those things, imho.

Multivolume can provide a little more flexibility with installed apps, though, if you are needing to rebuild a volume for some reason. I like to put an old drive of some sort that is not included in any raid volume so I can move installed apps to it in the event I need to reconfigure the main volume for some reason.

EXPI9404PTLBLK should be supported. I am using the dual ports in my Xpenology hardware instances and using the quads in my ESXi instances (doesn't mean it is for sure supported in Xpenology hardware instances, but they are the same chipsets).

GaryM - that is an intel chipset. Seriously - keep up.