On Monday, March 16 2009, David Cantrell said: > On 03/16/2009 03:19 AM, Jeremy Katz wrote: >> On Sunday, March 15 2009, David Lehman said: >>>>> Why not just do a temporary mount somewhere (if not already mounted) and >>>>> run statfs on it? Wouldn't that be simpler?</hand_wave> >>>> It would be. Attached is a new patch. I didn't know we could call >>>> statvfs() from Python (nor did I ever bother to look, but whatever). >>> Much nicer. >> >> Mounting can entail side effects, though, such as journal recovery and >> has also in some cases ended up with filesystems having new, >> incompatible features enabled. While I guess it's possible that running >> dumpe2fs, etc on a filesystem could do similar things, it just feels a >> lot less likely. > > While I'm not crazy about mounting the filesystem to get the existing > size, I do like using statvfs(). We won't have to worry about parsing > output from a variety of commands and we won't have to worry about > subtle changes in the output that breaks installations later on. I hardly am a fan of parsing command line output from things... my kingdom for a library that gives this sort of information. Once upon a time, it was to be part of parted's calling in life. It's not anymore. Maybe it should be something like libblkid (I can hear sandeen screaming from here), dunno. > I'd rather work around the problems with mounting and running statvfs() > than try what I initially wrote. We should definitely at least be mounting read-only. But that doesn't, provide any guarantees about things like journal recovery or anything else that could modify filesystem features. I really don't know how we just work around those problems without a concerted effort to get something like a 'DontTouchAnythingIMeanIt' mount flag plumbed down into all of the kernel fs code. Jeremy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
