|
Bugzilla – Full Text Bug Listing |
| Summary: | fstests btrfs/276 failed | ||
|---|---|---|---|
| Product: | [SUSE ALP - SUSE Adaptable Linux Platform] Granite | Reporter: | Long An <lan> |
| Component: | Kernel | Assignee: | Wenruo Qu <wqu> |
| Status: | IN_PROGRESS --- | QA Contact: | |
| Severity: | Normal | ||
| Priority: | P2 - High | CC: | jalausuch, jcheung, rgoldwyn, rtsvetkov, sweiberg, yosun |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Long An
2023-07-28 07:46:15 UTC
This seems to be a false alert that the test case doesn't take into consideration. The test case itself requires 128K compressed extents, but this is done by writing a 16G file with 8M block size. There is no guarantee that our writeback is going to always create the maximum size of file extents. If there is any memory pressure (considering the file size is pretty large, it's pretty possible) we can writeback smaller extents and lead to more than expected number of extents. This seems to be problem in the test case itself, but I failed to reproduce locally with 4G VM RAM. I can update the test case to handle it more correctly soon. BTW, where can I find the RAM size of the VM? (In reply to Wenruo Qu from comment #2) > BTW, where can I find the RAM size of the VM? http://10.67.133.133/tests/288#settings In test settings, QEMURAM=4096 And I'll also update test code to print this OK, I also got one hit of the false alert, with the same increased number of extents. Would be much easier to verify the fix now. Filipe has updated the test case to address the problem, his fix is already merged now: 24cfe625794e ("btrfs/276: make test accurate regarding number of expected extents")
Mind to check if the newer fstests solved the false alerts?
|