On Mon, 29.07.13 16:52, Ric Wheeler (rwheeler@xxxxxxxxxx) wrote: > >Oh, we don't assume it's all ours. We recheck regularly, immediately > >before appending to the journal files, of course assuming that we are > >not the only writers. > > With thinly provisioned storage (or things like btrfs, writeable > snapshots, etc), you will not really ever know how much space is > really there. Yeah, and that's an API regression. On btrfs you can just add/remove device as you wish during runtime and statvfs() does refelct this immediately. thinp should work the same. Of course, this requires that the block layer has to pass more metadata up to the file systems than before, but there's really nothing intrinsicly evil about that, I mean, it could be as basic as just passing along a "provisioning perentage" or so which the fs will simply multiply into the returned values... (Of course it won't be that simple, but you get the concept...) > I am starting to think that this is critical enough that we might > want to always fully provision this - just like we would for audit > logs.... > > Checking won't hurt anything, but the storage stack will lie to you > (and honestly, we always have in many cases :)). Well, journald is totally fine if it is lied to in the sense that the values returned by statfs()/statvfs() are just estimates, and not precise. However, it is assumed that the values are not off by > 100% as they might be on thinp... That the values are not perfectly accurate has been known forever. Since file systems existed developers knew that book-keeping and stuff means the returned valuea are slightly higher than practically reachable. And since compressed file systems they also knew that they might be lower than actually reachable. However, it's one thing to return bad estimates, and it is another thing to be totally off in the woods as is the case for thinp! > There are some alerts that we can raise when you hit a low water > mark for the device mapper physical pool, it would be interesting to > talk about how you might leverage these. Well, the point I am making is that it is wrong to ask userspace to handle this. Get the APIs right you expose to userspace. I mean, ultimately for me it doesn't matter I geuss, since you say neither the fs/block layer nor userspace should care, but that this is the admin's problem, but that really sounds like chickening out to me... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
