Is it "oh yeah, known problem, don't use iSCSI, you are f*cked but paid support can help you recover the data" or "Have not seen this particular sequence earlier, maybe support'll know"........?
Restaring NAS after iSCSI problems -> stuck on "Restarting Now See You Soon".
Note: the NAS thinks there is an iSCSI connection from the PC, the PC thinks otherwise and is not able to reconnect.
Noticed that the btrfs-transacti command was using 100% CPU before I was kicked out of SSH.
Booting. Stuck at 42% for long time again. So same symptoms as before. *waiting*. NAS is not visible to RAIDar at this point. udev-settle.service issues? 25+ minutes now.
Is it "oh yeah, known problem, don't use iSCSI, you are f*cked but paid support can help you recover the data" or "Have not seen this particular sequence earlier, maybe support'll know"........?
Closer to the latter. Failure to boot with possibility of data loss, complicated by the fact that iSCSI data is opaque to the NAS. I was assuming that you had no backup (though that was a guess).
Though it looks like you've also installed stuff with ssh (pilgrim anyway), which could complicate things further.
Closer to the latter. Failure to boot with possibility of data loss, complicated by the fact that iSCSI data is opaque to the NAS. I was assuming that you had no backup (though that was a guess).
Though it looks like you've also installed stuff with ssh (pilgrim anyway), which could complicate things further.
Any idea what mount is mounting?
I only installed mc (midnight commander).
pilgrim appears to be what controls the front panel LCD of the NAS.
Usage: pilgrim [-c] [-l path] [ -p path] [-s hex] [-t "term cmd"] [-u file] -c Clear LCD on termination -l Message list file path(/var/readynasd/pilgrim.list) -p Socket path (\0/org/freedesktop/plymouthd) -s Solid box character code in hex (ff) -t Termnation cmd (none) -u Termnation unit ("readynasd.service")
In essence, I believe there are issues with iSCSI implementation. 😕
Clearly something is wrong, but I don't think you've isolated it to iSCSI just yet. Lots of things will misbehave when the system is running at 98% CPU.
I have created a new LUN with thick privisioning and moved data there. This seems more stable, however iSCSI dropped out again (normal shares work fine).
What I have noticed is that every time the iSCSI drops the btrfs-transacti is running at 100% (i.e one core full load).
The btrfs-transacti will eventually calm down and iSCSI pops up again without NAS restart (although Windows may or may not be confused at that point and PC restart may be necessary, have not kept track of this fully).
So my current guess is:
* Something triggers this btrfs storm
* This affects iSCSI which drops
* Restarting the NAS at this point should be avoided
I am guessing that this btrfs-transacti is doing something useful. But I would consider dropping the iSCSI as a product bug.
Did you create a Thick or a Thin LUN? You are probably experiencing fragmentation. btrfs-transaction is probably having a hard time with the level of fragmentation on your LUN and causing instability.
