ogi

Hmm...booted in UEFI mode; getting different behavior. Array starts fine, I start the VM, it registers as running, but the VM never becomes available via splashtop. Eventually I connect a monitor, and monitor says "The current input timing is not supported by the monitor display. Please change the input timing to <resolution> @ <refresh_rate> ..." Guess the next thing to try is removing the GPU from the passthrough device and see what happens. EDIT: I'm unable to stop the VM normally, had to Force Stop it. EDIT2: Forced stopped the VM, removed the GPU, booted with VNC fine, stopped the VM normally, re-added the GPU, same kernel panic (IOW UEFI boot made no difference). Trying the other available slot now (yay for the baby sleeping for long period of time letting me try out these different configs!) EDIT3: No luck with moving the GPU. Moved the GPU to its adjacent slot, used the VFIO plugin to bind the devices in that IOMMU group, started the VM with the non-header-removed vbios, got a error code 43, then I referenced the vbios with the header removed, and got the same kernel panic as earlier. I came across this site which has some other suggestions I may try: https://github.com/intel/nemu/wiki/Testing-VFIO-with-GPU

Thanks for the reply @bastl As this card has a 2-slot width, there is only one other slot I can try to plug it into. That second on my list of things to try besides trying to boot unraid via UEFI, which was a suggestion in some other forums with this sort of error. Regarding the vbios, I did grab a vbios from techpowerup, but.... I flashed that vbios to my card, then dumped the vbios shortly after (because why not) and modified the header per spaceinvaderone's video. Flashing the techpowerup bios is what allowed the GPU to "work" (for a few seconds anyway) because the BIOS on there to begin with did not support UEFI booting, which as I saw on the wiki, is a requirement for OVMF. The reason I can tell it was working momentarily was that the monitor I had the GPU connected to showed the login screen at the correct resolution, and the splashtop streaming client also adjusted to an "appropriate" resolution. I'll be following up a bit more. With the covid-19 pandemic, my plex server has been getting used a little more heavily than usual, so it's tough to come up with some downtime that won't impact folks.

Just a follow up, I migrated from Nvidia - Unraid 6.8.2 to standard Unraid 6.8.3, and still have this issue.

Digging through the syslog myself, these appear to be the last two entries before the kernel panic Mar 11 17:55:20 Tower kernel: vfio_bar_restore: 0000:83:00.0 reset recovery - restoring bars Mar 11 17:55:24 Tower kernel: vfio_bar_restore: 0000:83:00.0 reset recovery - restoring bars The device 83:00.0 is the GPU I'm trying to pass through.

Hello Unraid community, I'm hoping that I can get some help because I am stumped! I'm trying to pass-through a GTX 670 GPU into a Windows VM for the purposes of running a nvidia gamestream host. Unfortunately, when I try and passthrough the GPU into the VM, Unraid has a kernel panic, with following message (I should note that when using Splashtop Personal (or having the GPU connected to a monitor), the graphics card is clearly recognized, and the resolution starts adjusting accordingly). Kernel Panic - not syncing; Timeout: Not all CPUs entered broadcast exception handler. Using VNC without the GPU, everything works as expected. Hardware in question: Motherboard X9DRi-LN4F+ GPU: Gigabyte GTX 670 - Flashed with UEFI capable VBIOS BIOS and IPMI/BMC are updated to latest versions posted on Supermicro's website I've attached the XML config for the VM to this post. I have a vfio-pci.cfg file with the following content (those are the PCI addresses for the GPU). BIND=83:00.0 83:00.1 The IOMMU group consists of strictly those devices I've tried various options in the syslinux.cfg, haven't found anything that worked, but for this last run that I collected data, this is what that file looked like: default menu.c32 menu title Lime Technology, Inc. prompt 0 timeout 50 label Unraid OS menu default kernel /bzimage append isolcpus=16-19,36-39 pcie_aspm=off video=vesafb:off,efifb:off initrd=/bzroot label Unraid OS GUI Mode kernel /bzimage append isolcpus=16-19,36-39 initrd=/bzroot,/bzroot-gui label Unraid OS Safe Mode (no plugins, no GUI) kernel /bzimage append initrd=/bzroot unraidsafemode label Unraid OS GUI Safe Mode (no plugins) kernel /bzimage append initrd=/bzroot,/bzroot-gui unraidsafemode label Memtest86+ kernel /memtest Before I started the VM, I made sure I had syslog mirroring on the USB running, so I captured the syslog, and I've attached it to this post as well. Lastly, the diagnostics are attached too.... I was having a lot of Error code 43 issues, but once I flashed the GPU with the UEFI capable vbios, it seemed to work for a bit (resolution adjusted to monitor native resolution...then seconds later, kernel panic). This effort has been somewhat difficult to be iterative about, as each time I attempt to start the VM, it requires I perform a parity check after. If anyone here has any suggestions, or something sticks out to them in the diagnostics or syslog, please let me know; I'm all out of ideas. I should also add, I'm not above going out and getting a different GPU if there is evidence to suggest that's the culprit. tower-diagnostics-20200311-1839.zip vfio-pci.cfg windows-vm.xml syslog

I have the same GPU, did a bunch of research; eventually discovered that the passthrough devices need to support UEFI boot, which this Gigabyte card does not support. I'll be trying to flash the vbios linked in that thread to my GPU and see if it works any better.

Following up on this, I ended up rebuilding my USB due to another error, and this issue has gone away.

I am having the same issue with my x9dri-ln4f+ system as well (attached diagnostics when the system rebooted as well as the screenshot from the KVM view moments after starting the VM). Here is the XML configuration for said VM: <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm'> <name>Windows 10</name> <uuid>65af8239-80de-8ddd-35e7-a0dbf8de19c5</uuid> <description>Gaming Platform</description> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>16777216</memory> <currentMemory unit='KiB'>16777216</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>8</vcpu> <cputune> <vcpupin vcpu='0' cpuset='16'/> <vcpupin vcpu='1' cpuset='36'/> <vcpupin vcpu='2' cpuset='17'/> <vcpupin vcpu='3' cpuset='37'/> <vcpupin vcpu='4' cpuset='18'/> <vcpupin vcpu='5' cpuset='38'/> <vcpupin vcpu='6' cpuset='19'/> <vcpupin vcpu='7' cpuset='39'/> </cputune> <os> <type arch='x86_64' machine='pc-i440fx-4.2'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/65af8239-80de-8ddd-35e7-a0dbf8de19c5_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='none'/> </hyperv> </features> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='4' threads='2'/> </cpu> <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source dev='/dev/disk/by-id/ata-WDC_WDS200T2B0A-00SM50_20053B800394'/> <target dev='hdc' bus='sata'/> <boot order='1'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/ISOs/Win10_1909_English_x64.iso'/> <target dev='hda' bus='ide'/> <readonly/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/ISOs/virtio-win-0.1.173-2.iso'/> <target dev='hdb' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:95:eb:d8'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x83' slot='0x00' function='0x0'/> </source> <rom file='/mnt/user/domains/Gigabyte.GTX670.2048.120914.rom'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x83' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> </hostdev> <memballoon model='none'/> </devices> </domain> tower-diagnostics-20200304-0627.zip EDIT: On reboot, the GPU was not accessible from the unraid UI, I removed the GPU and soundcard entry, and the VM started without issue. Now to figure out what happened to my GPU, and why trying to pass it through unraid to have a kernel panic.

I managed to restore the functionality I had previously. First, I disabled "load config @ unraid start", then I restored the BMC to factory settings. I then booted up and copied fan.cfg, ipmi.cfg into the directory and copy/pasted the contents of ipmi-sensors.config into the editor. The changes took. For now I'll leave the system as is, unless there is some debug information you would be interested in having dmacias. Thanks again for this plugin, if it wasn't for your work, my wife would give me the death glare at every opportunity

BMC/IPMI firmware is up to date (3.48) and BIOS version is 3.3, as far as I can tell, those are the latest versions for the motherboard (X9DRi-LN4F+) https://www.supermicro.com/products/motherboard/Xeon/C600/X9DRi-LN4F_.cfm

Follow up part 2; so after having the system run stable for a few days as expected, I decided to yank out the fans connected to the FAN5 and FAN6 headers (was planning on doing this anyway as they do not provide much cooling at this point). Unfortunately this has resulted in the same behavior as before, where regardless of what i set the minimum fan speed percentage to be, the fans go to effectively 0 RPM, and the critical threshold kicks in, bringing the fans connected to FAN1, FAN2 and FAN3 connectors to 100%. I'm starting to be suspicious that this may be a motherboard specific issue...

Huh, is there any other log I can lookup to see what's was happening (or in my case, was not happening)? The contents of /var/log/ipmifan appear correct....

Just following up earlier posts, things are going well a day later; .... i think one of the issues I was fighting, and what originally caused this whole thing to begin with was that I removed some fans....which on its own I think is fine, but doing IPMI fan control on a section that is 'missing' fans probably won't work, so until the IPMI interface knows to not even bother looking for them, ....probably shouldn't worry about fans spooling up to 100%.... That said I'd like to reboot the server a bunch more to make sure things come back up as expected; it's undergoing too much use for now.

muahahahaha I finally got it I think. What was missing was that I was missing a few sensors from the "Display Settings/Global Available Sensors". Things started to work when I enabled the two HDD Status snesors (both read N/A) and PCH Temp; I added all those at the same time, so I'm not sure which one specifically did the trick. EDIT: thanks you dmacias for making this plugin and providing assistance in these threads! EDIT2: Rebooted the machine, still having the same problem, when I enable fan control, fans report 0 RPM, and then go full bore.... but when reporting 0 rpm, fans are actually spinning under power.... EDIT3: on another reboot, fans are spinning at 225rpm ....and not in the critical zone, so yay?

okay, things are weird, I decided to open up the chassis to see what's going on, turns out while the reading reports 0 RPMs, the fans are still actually spinning....so I suppose this is a problem of an incorrect fan speed reading....

Thanks for the reply, for some reason my sensor seems to want multiples of 75, so 200 would not work: When I set to 300, I still get the same behavior described earlier. Here is the ipmi log, the log indicates the plugin is trying to do things correctly, but for some reason the fan is just going to 0, then the fan spools up again to 100% 2020-02-22 07:29:07 Starting Fan Control 2020-02-22 07:29:07 Setting fans to full speed 2020-02-22 07:29:17 Fan:Temp, FAN1234(32%):CPU1 Temp(31°C), FANA(36%):HDD Temp(0°C) 2020-02-22 07:30:17 Fan:Temp, FAN1234(31%):CPU1 Temp(24°C), FANA(36%):HDD Temp(0°C) 2020-02-22 07:30:40 Stopping Fan Control 2020-02-22 07:30:40 Setting fans to auto 2020-02-22 07:31:56 Starting Fan Control 2020-02-22 07:31:56 Setting fans to full speed 2020-02-22 07:32:06 Fan:Temp, FAN1234(31%):CPU1 Temp(24°C), FANA(36%):HDD Temp(25°C) 2020-02-22 07:32:16 fan control config file updated, reloading settings 2020-02-22 07:32:17 Fan:Temp, FAN1234(31%):CPU1 Temp(25°C), FANA(36%):HDD Temp(25°C) 2020-02-22 07:33:57 fan control config file updated, reloading settings 2020-02-22 07:33:57 Fan:Temp, FAN1234(31%):CPU1 Temp(25°C), FANA(40%):HDD Temp(25°C) 2020-02-22 07:35:58 Fan:Temp, FAN1234(35%):CPU1 Temp(33°C), FANA(40%):HDD Temp(27°C) 2020-02-22 07:36:59 Fan:Temp, FAN1234(31%):CPU1 Temp(30°C), FANA(40%):HDD Temp(27°C) 2020-02-22 07:38:09 fan control config file updated, reloading settings 2020-02-22 07:38:09 Fan:Temp, FAN1234(31%):CPU1 Temp(28°C), FANA(50%):HDD Temp(27°C)

See the first post about setting Supermicro critical thresholds with the sensor config editor. Screenshot above showed I modified the critical thresholds; but the original post said to put all the values between 200 and 300, which I have now done, but still have the same issue: Again, doesn't matter what I set the minimum fan speed percentage at, when I hit apply, the fans just go to 0 RPM. Also for reference, this is the relevant section of the config file: Section 2684_FANA ## Possible values: Yes/No Enable_All_Event_Messages Yes ## Possible values: Yes/No Enable_Scanning_On_This_Sensor Yes ## Possible values: Yes/No Enable_Assertion_Event_Lower_Critical_Going_Low Yes ## Possible values: Yes/No Enable_Assertion_Event_Lower_Non_Recoverable_Going_Low Yes ## Possible values: Yes/No Enable_Assertion_Event_Upper_Non_Critical_Going_High Yes ## Possible values: Yes/No Enable_Assertion_Event_Upper_Critical_Going_High Yes ## Possible values: Yes/No Enable_Assertion_Event_Upper_Non_Recoverable_Going_High Yes ## Possible values: Yes/No Enable_Deassertion_Event_Lower_Critical_Going_Low Yes ## Possible values: Yes/No Enable_Deassertion_Event_Lower_Non_Recoverable_Going_Low Yes ## Possible values: Yes/No Enable_Deassertion_Event_Upper_Non_Critical_Going_High Yes ## Possible values: Yes/No Enable_Deassertion_Event_Upper_Critical_Going_High Yes ## Possible values: Yes/No Enable_Deassertion_Event_Upper_Non_Recoverable_Going_High Yes ## Give valid input for sensor type = Fan; units = RPM Lower_Non_Critical_Threshold 225.000000 ## Give valid input for sensor type = Fan; units = RPM Lower_Critical_Threshold 225.000000 ## Give valid input for sensor type = Fan; units = RPM Lower_Non_Recoverable_Threshold 225.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Non_Critical_Threshold 3000.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Critical_Threshold 3000.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Non_Recoverable_Threshold 3000.000000 ## Give valid input for sensor type = Fan; units = RPM; 'None' to not use hysteresis Positive_Going_Threshold_Hysteresis 75.000000 ## Give valid input for sensor type = Fan; units = RPM; 'None' to not use hysteresis Negative_Going_Threshold_Hysteresis 75.000000 EndSection Section 2751_FANB ## Possible values: Yes/No Enable_All_Event_Messages Yes ## Possible values: Yes/No Enable_Scanning_On_This_Sensor Yes ## Possible values: Yes/No Enable_Assertion_Event_Lower_Critical_Going_Low Yes ## Possible values: Yes/No Enable_Assertion_Event_Lower_Non_Recoverable_Going_Low Yes ## Possible values: Yes/No Enable_Assertion_Event_Upper_Non_Critical_Going_High Yes ## Possible values: Yes/No Enable_Assertion_Event_Upper_Critical_Going_High Yes ## Possible values: Yes/No Enable_Assertion_Event_Upper_Non_Recoverable_Going_High Yes ## Possible values: Yes/No Enable_Deassertion_Event_Lower_Critical_Going_Low Yes ## Possible values: Yes/No Enable_Deassertion_Event_Lower_Non_Recoverable_Going_Low Yes ## Possible values: Yes/No Enable_Deassertion_Event_Upper_Non_Critical_Going_High Yes ## Possible values: Yes/No Enable_Deassertion_Event_Upper_Critical_Going_High Yes ## Possible values: Yes/No Enable_Deassertion_Event_Upper_Non_Recoverable_Going_High Yes ## Give valid input for sensor type = Fan; units = RPM Lower_Non_Critical_Threshold 225.000000 ## Give valid input for sensor type = Fan; units = RPM Lower_Critical_Threshold 225.000000 ## Give valid input for sensor type = Fan; units = RPM Lower_Non_Recoverable_Threshold 225.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Non_Critical_Threshold 3000.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Critical_Threshold 3000.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Non_Recoverable_Threshold 3000.000000 ## Give valid input for sensor type = Fan; units = RPM; 'None' to not use hysteresis Positive_Going_Threshold_Hysteresis 75.000000 ## Give valid input for sensor type = Fan; units = RPM; 'None' to not use hysteresis Negative_Going_Threshold_Hysteresis 75.000000 EndSection

Hello, Thanks for writing this plugin dmacius. I'm having an issue with some fans spinning at 100% no matter what (do not think this is a bad threshold issue). For context, I'm running unraid 6.8.2,I have a CSE-846 chassis, with X9DRI-LN4F+ motherboard, and 3x iPPC Noctua 3000 fans for the "fanwall", as well as some fans for my CPU coolers. The CPU fans are running consistently as they should (I will +1 the earlier suggestion of adding a temperature option of having the CPU fans be driven by max(Temp_CPU1, Temp_CPU2)). The problem is with the 3x iPPC noctua fans in the fanwall. When I adjust a setting regarding, say minimum fan speed, the fans go to 0, and then the threshold limitation kicks on, and they spool up to 100%. What is odd here is that it doesn't matter what I set the minimum fan speed to, the fans will always go to 0 rpms, I've set minimum fan speeds of over 80%, doesn't matter, they go to 0 rpms, then I assume the threshold kicks in and spools them to 100% (but I can't be certain). I have tried the fan wall fans to be plugged into FAN1/2/3 headers, and I've tried them plugged in the FANA/B header (using a 2-1 splitter on one of the connectors), but I have right now the fans connected into FANA/B connectors and the CPU connectors plugged into FAN4 (using a 2-way splitter). I think the plugin is trying to set the fan speed accordingly. Here is a segment from my /var/log/ipmifan logfile: 2020-02-21 22:42:31 fan control config file updated, reloading settings 2020-02-21 22:42:32 Fan:Temp, FAN1234(38%):CPU1 Temp(35°C), FANA(32%):HDD Temp(35°C) 2020-02-21 22:44:33 Fan:Temp, FAN1234(35%):CPU1 Temp(33°C), FANA(32%):HDD Temp(35°C) 2020-02-21 22:45:33 Fan:Temp, FAN1234(31%):CPU1 Temp(30°C), FANA(32%):HDD Temp(35°C) 2020-02-21 22:47:34 Fan:Temp, FAN1234(37%):CPU1 Temp(34°C), FANA(32%):HDD Temp(35°C) 2020-02-21 22:48:34 Fan:Temp, FAN1234(38%):CPU1 Temp(35°C), FANA(32%):HDD Temp(35°C) If I look at my Readings page tho, you can see the results in the image. Is there anything else I can check/do? Thanks again.

I'm not sure if it's a seperate issue I'm having, but while removing a second disk, I'm having problems with 'syncing disks'. I attempted to restart a docker container (Plex Media Server) while the clear-disk script was running. The container won't stop, it appears to be stuck on [s6-finish] syncing disks ... I've been trying to kill the container with no luck. Current plan is to let the clear disk script finish on the current disk, then force a shut-down/restart (will likely have to manually umount all my disks). Anyway I don't think this issue is directly due to the script so much as the suggested setting md_write_method to reconstruct write (from auto or read/modify/write). Given that that setting is suggested, I'm going to try running through this script next time around w/ read/modify/write setting instead (full well knowing it will take longer), and see if I have sync filesystem or sync disks issues then.

After a little over an hour of sync-ing, I powered the machine off, let it come up, it's doing a parity check now, but the disk I was running this before is labeled as unmountable, so as soon as the parity check completes, I'll resume the shrink array procedure from step 9. https://wiki.lime-technology.com/Shrink_array

I just ran this script, while completed without issue, when I have gone to stop the array, the array is taking a long time to sync filesystems... is this normal (I'm currently passing 20 minutes)?

Did those steps, got the web gui up, but it didn't like the location of ConfigTemplate ConfigTemplate=/config/nzbget.conf Modified that line and I was back up and running

Since making this post, you guys have had a lot on your plate (especially w/ the reiserFS corruption issue, etc), just wondering if there is any other data I can provide relevant to enable this feature. I found some "guides" to get the shadow copy volumes setup on a linux server: http://www.linuxtopia.org/online_books/network_administration_guides/samba_reference_guide/30_VFS_13.html Here is some actual documentation on the samba module: https://www.samba.org/samba/docs/man/manpages/vfs_shadow_copy2.8.html I would be happy to seek out more information, but again, I am unaware of the technical challenges of such an implementation. Thanks, Ogi Ogi, thanks for your patience with us. I want to explore this further but we are about to go on a feature freeze for 6.0. Need to clamp down what we have first before we can add any more. That said, this sounds like something we for sure would want to look into for our windows users. Thanks for the fast reply! I know you guys are approaching the RC phase of v6.0 (and with that comes a feature freeze), don't worry, I have my expectations in check. I guess I would just like to have an idea of what kind of difficulty implementation of the volume shadow copy module would be (is this a minor undertaking, major undertaking?). From what I've read it looks like it just leverages existing snapshots (BTRFS supported feature if I understand correctly). That said, I'm glad you're able to see the value in a feature such as this, I know at work being able to quickly recover a network file (going to a "previous version") has gotten me out of a jam more than once. Thanks again Jon

Since making this post, you guys have had a lot on your plate (especially w/ the reiserFS corruption issue, etc), just wondering if there is any other data I can provide relevant to enable this feature. I found some "guides" to get the shadow copy volumes setup on a linux server: http://www.linuxtopia.org/online_books/network_administration_guides/samba_reference_guide/30_VFS_13.html Here is some actual documentation on the samba module: https://www.samba.org/samba/docs/man/manpages/vfs_shadow_copy2.8.html I would be happy to seek out more information, but again, I am unaware of the technical challenges of such an implementation. Thanks, Ogi

I hadn't thought of it that way, but that sounds about right. I'm on my phone so pardon the lack of formatting. Here is an instructional guide showing its use: http://www.engineering.uiowa.edu/ecs/support/previous-version From the wikipedia page it says this feature is available on LVM based storage (for samba servers that aren't windows) https://en.m.wikipedia.org/wiki/Shadow_Copy