3 ms·
Existing data is unlikely to be lost, but I strongly suggest that existing systems get off 0.7.7 if they are on it. Having to figure out where the orphaned file
by ryao 9y ago
Existing data is unlikely to be lost, but I strongly suggest that existing systems get off 0.7.7 if they are on it. Having to figure out where the orphaned files belonged would be very inconvenient.
- luke0016 9y agoI have a fairly specific question - I'm in the process of migrating a large array onto another disk using zfs send and receive (6TB). It's been at it for about 2 days now. After the migration, I plan to destroy and recreate a larger array and send it back. If the pool is not being read/written to by anything else, am I safe? Or should I stop the send and receive and downgrade? Thank you for the hard work.
- ryao 9y agoYou should be fine. The DMU that handles send/recv is unaffected as long as the snapshots at the source were not taken after 0.7.7 experienced an ENOSPC on file creation.
- luke0016 9y agoAs far as I know, it has never experienced an ENOSPC error. It was mentioned elsewhere that a procedure is being developed to detect orphaned files that arise from this bug. Would it be a good idea for me to keep the original array around long enough to run through that procedure just in case?
- ryao 9y agoI am the developer who volunteered to develop the code to fix things. Anyway, there is no reason to avoid send/recv with 0.7.7. Send/recv will neither trigger this bug nor make it worse if it were triggered.
- luke0016 9y agoI understand - what I meant to say is that I cannot be sure that the array never ran into an ENOSPC issue prior to the snapshot. Given that, should I keep the old array around until I can do whatever is recommended to detect potential orphans resulting from the bug? Edit: And thank you, again.
- ryao 9y agoThere is no reason to do that here. Send/recv makes a perfect copy as far as this is concerned. You are welcome. Also, the proper term is pool.