Bug 500484
Summary: | GFS2: libgfs2's buffering system needs to be overhauled | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Robert Peterson <rpeterso> |
Component: | gfs2-utils | Assignee: | Robert Peterson <rpeterso> |
Status: | CLOSED DUPLICATE | QA Contact: | Cluster QE <mspqa-list> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 5.3 | CC: | adas, edamato, esandeen, swhiteho |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-11-19 14:37:46 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 455300, 568446 | ||
Bug Blocks: |
Description
Robert Peterson
2009-05-12 21:36:31 UTC
Keeping Eric Sandeen in the loop, mainly because bug #455300 was his baby. I think probably that eliminating it entirely would be a better plan. If we want to read the fs, then we could just mmap() it. That would allow us to have a r/o mapping in the case that we were not intending to modify the blocks and hence catch any incorrect code. Also it means that the blocks are backed by the fs and this allows writeback when it is required in a more sensible order than with the existing scheme. We would also be able to drop hints with madvise() and msync() to help speed things up. We'd need to ensure that we map things in batches due to the limited amount of virtual memory available on 32 bit arches (we couldn't be certain to map a complete rgrp at once, for example) In fact a good plan, would be to always mmap() read-only, and use remap_file_pages() to make them read-write only when we need to write to them. Think of it as building in ElectricFence as part of the design :-) I know at some time in the past, we did consider looking into changing the existing scheme to use mmap()ed buffers and that there was some reason why the change wasn't trivial. I forget what that was now... The real question I guess, is whether its better to start from scratch (I think it may well be) or to try and force this into the existing tools. I scraped my previous patch for this and reworked everything as part of bug #455300, for improving the speed of fsck.gfs2. The replacement buf.c is a tiny shell of its former self. It's merely a convenient way to read, write and store data with really no buffering and no linked lists as before. So I'm closing this as a duplicate of that one. That fix is nearly complete. At least fsck.gfs2 seems to work mostly, but I need to do a lot of testing for all gfs2 user space tools. *** This bug has been marked as a duplicate of bug 455300 *** |