Chris Mason <chris.mason@oracle.com> writes:Ok. So the journal code here fundamentally depends on being able to control the order of the writes, and something else being able to set the buffer head dirty messes up that control. It makes no sense to implement a ramdisk in a way that requires this. Looks like it. There are even comments in jbd about the same class of problems. Apparently dump and tune2fs on mounted filesystems have triggered some of these issues. The practical question is any of this trouble worth handling. Thinking about it. I don't believe anyone has ever intentionally built a filesystem tool that depends on being able to modify a file systems metadata buffer heads while the filesystem is running, and doing that would seem to be fragile as it would require a lot of cooperation between the tool and the filesystem about how the filesystem uses and implement things. Now I guess I need to see how difficult a patch would be to give filesystems magic inodes to keep their metadata buffer heads in. Eric -
| Heiko Carstens | [patch -mm] s390: struct bin_attribute changes |
| Andrew Morton | 2.6.25-rc2-mm1 |
| Eric W. Biederman | Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jens Axboe | Re: [BUG] New Kernel Bugs |
| Andrew Morton | Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes |
