Closed rinor closed 1 year ago
When a volume (root or otherwise) is near 100% usage and a write fails due to insufficient free space, there shouldn't be any panic or filesystem corruption: the kernel just returns the ENOSPC error number to indicate lack of disk space. I'm not aware of any known issues, the TFS log code reserves upfront the disk space it may need. Of course, if you find any bugs or unhandled edge cases, you are more than welcome to report them!
Having some data corruption issues while performing initial tests. Will start with the first one:
power of 2
for now, 1MiB, 2MiB, 4MiB, 8MiB,..) files with the same random generated data until you get a failure (ENOSPC
)Software
versionsCode
usedOPS
configTest Result (4MiB)
corruptedIn here I'm posting the test result for 4MiB case, since all other cases (2, 4, 8, 16, ...)MiB behave the same.
The test app code and the test steps you described seem correct to me, so there may indeed be some corruption issues. We'll take a look.
Not sure if it's related, but when building/running nanos with TLOG_DEBUG_DUMP
defined there is an assertion failing (the same fails when running images)
assertion b->start + offset <= b->length failed at /usr/local/src/nanos/src/runtime/buffer.h:31 in buffer_ref(); halt
TLOG_DEBUG_DUMP
definedI reproduced the issue and found its cause. Will be fixed in https://github.com/nanovms/nanos/pull/1862. As for the assert failure when TLOG_DEBUG_DUMP is defined, it's unrelated to this issue, and is due to the debug code that has not been updated when we changed the implementation of the TFS log.
ok, tested that pr and so far all good. All scenarios that previously failed, now behave correctly.
The next observation was about abnormal memory usage (possible memory leak) under some heavy r/w file ops. Will test https://github.com/nanovms/nanos/pull/1861 since it looks like it's related.
prevent/protect
data corruption and kernel crash in the following test case:
write as fast as you can without explicitely waiting for the data to be flushed on disk
Is there a way for the kernel (+fs) to handle this safer/better?
OPS
configTest Result
corrupted/pagecache crashWIth #1904, the above data corruption and kernel crash issues are fixed, and the application can write as fast as it can without waiting for data to be flushed to disk.
WIth #1904, the above data corruption and kernel crash issues are fixed, and the application can write as fast as it can without waiting for data to be flushed to disk.
Testing that pr and now it's much better. However while testing, randomly (have yet to identify a pattern and exclude test env fault) got some failures. Just posting so we have them here.
@rinor I added a commit in #1904 that fixes the latest issue you found. Thanks
@rinor I added a commit in #1904 that fixes the latest issue you found. Thanks
Much better now. Questions:
pagecache_commit_dirty_ranges error: sgbuf alloc fail
? It happens when writing data and sometimes it causes page faults
@rinor both errors you reported are due to a failed allocation of buffers that the kernel uses in its internal scatter-gather lists, which can happen when the system is under memory pressure. I modified #1904 again so that these allocation failures are less likely, and if they happen the kernel can recover from them.
I modified #1904 again so that these allocation failures are less likely, and if they happen the kernel can recover from them.
So far all looks good and much more reliable, can't crash/corrupt anything anymore. Thank you.
I'm about to start testing nanos filesystem/storage stability. Mostly interested in data storage r/w correctness/corruption and system memory requirements/relationships between r/w data size/frequency on "root" partition/drive/volume and also on additional "mounted" volumes/drives.
I.e:
I'll report the findings once tested, but I am curious if there are any known "issues" you are aware of in general or unhandled edge cases.