Open zacsimile opened 12 months ago
OK, hmm. It is wrapped in try
/except
already. I have to look more into this.
It looks like the except
is not receiving an OSError
. I'm wondering if this error is caught at a lower level and not passed up to where the except
call is. It's very hard to prove this as many of the h5py files are compiled and hard to test as we usually have plenty of disk space. I think we need to write a test using pyfakefs
(https://pytest-pyfakefs.readthedocs.io/en/latest/usage.html) (see https://stackoverflow.com/questions/70887330/mocking-disk-out-of-space-in-python-unittests and https://stackoverflow.com/questions/19672138/how-do-i-mock-the-filesystem-in-python-unit-tests?rq=4) to simulate a small filesystem and then we can see which errors are getting passed up to the ImageWriter
class.
It's back.
Traceback (most recent call last):
File "c:\users\dean-lab\desktop\aslm\src\aslm\model\features\image_writer.py", line 261, in save_image
self.data_source.write(
File "c:\users\dean-lab\desktop\aslm\src\aslm\model\data_sources\bdv_data_source.py", line 386, in write
self.image[dataset_name][zs, ...] = data[::dy, ::dx].astype(np.int16)
File "h5py\_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
File "h5py\_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
File "C:\Users\Dean-Lab\miniconda3\envs\ASLM\lib\site-packages\h5py\_hl\dataset.py", line 999, in __setitem__
self.id.write(mspace, fspace, val, mtype, dxpl=self._dxpl)
File "h5py\_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
File "h5py\_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
File "h5py\h5d.pyx", line 283, in h5py.h5d.DatasetID.write
File "h5py\_proxy.pyx", line 114, in h5py._proxy.dset_rw
OSError: [Errno 28] Can't write data (file write failed: time = Wed Nov 8 18:37:40 2023
, filename = 'D:\Nicole\Liver\NA\488myosin_561nuclear_647rfp\2023-11-08\Cell_001\CH00_000000.h5', file descriptor = 4, errno = 28, error message = 'No space left on device', buf = 00000199E5A37018, total write size = 16384, bytes this sub-write = 16384, bytes actually written = 18446744073709551615, offset = 162916425424)
Here is my latest traceback...
I know we check for disk space before starting an acquisition (#507), but it seems this is insufficient. An example of where this approach fails is copying data to the saving directory while the acquisition is running. In this case, the available space shrinks mid-acquisition with no alert. I think we need to wrap the
write
call in atry
/except
block and gracefully close when we are out of disk space. Unfortunately, closing requires a slight amount of disk space, so this may fail too. Still not quite sure how to handle this, but I think it's work just giving thetry
/except
a go. Perhaps another approach would be to "look ahead" one frame and cut off acquisition early. But, this sort of prediction may get us into trouble in the exact same example I provided above.