Thank goodness my company doesn't design jet engines!. The bit about getting the "horse" planted reminded me of how vulnerable we all are to that kind of attack vector. In depth story of industrial espionage, complete with social engineering Security.Still chewing on the idea of redoing this one dataset (but fixing it saves me time, so I keep hope up!) other than the data not being identical so, the slow send on this server, which has the used for one dataset showing incorrectly, could be due to large files, because this server has many more than the other server, or a " du -apparent-size" vs just " du" thing), but maybe it's due to this (my one real issue of slow send, is related to my other minor issue of size not being reported correctly)
HOWEVER, I still have a USED column being reported incorrectly (there's 32T of data in there, not 205K, like an empty dataset)Īnd I wonder if this is why my zfs send on this server is tens of MB, vs the zfs send on the other server being hundreds of GB in the same time (I have my pool split into two main datasets (with a bunch of child datasets) where one server sends it's main dataset (recursively) and receives the other dataset (recursively), and vice versa on the other server)-identical systems. NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD $ sudo zfs get receive_resume_token poo/datasetĪnd now this looks good per USEDCHILD (thank you always love being tidy!) Nice! that def was the weird child dataset usage you are correct: I tested a quick zfs send -t and then canceled, then tested the resume token (and then canceled and forgot about it, because it was a test a month or two)
0 kommentar(er)
