Hadmut Danisch posted on Sat, 28 Jan 2012 01:49:26 +0100 as excerpted: > Am 28.01.2012 00:20, schrieb Chester: >> It should be okay to mount with compress or without compress. Even if >> you mount a volume with compressed data without '-o compress' you will >> still be able to correctly read the data (but newly written data will >> not be compressed) > > But having both compressed and uncompressed files in the filesystem is > exactly what I want to avoid. Not because of reading problems, but to > avoid wasting disk space. I don't have a reading problem. I have a > writing problem.
Having a compression flag in the superblock (probably more than one, thus allowing indication of compression type, etc), which is I guess what you're suggesting, sounds useful to me too. Perhaps it'll get it, once development settles down a bit and they know enough about what's still missing in the existing superblock to be able to intelligently allocate flags, etc, on a priority basis based on what they then know they need. At this point I can certainly see a reluctance to make that change, tho, since it's a rather small change to make on its own, and with continuing tweaks to the compression types and etc, it's worth holding off committing now to what might look like a bad implementation down the line, when it has to continue to be supported. > I want to pack some data onto USB hard disks, which exceed the plain > disk capacity. With btrfs it works exactly the way as I need it, except > for the fact that once the compress option was missed the file system is > „tainted” with uncompressed files, thus wasting disk capacity and maybe > cause the files to not fit on the disk anymore. I'd be a bit leary of your whole idea of using btrfs on external drives attached to multiple systems, at this point. There's still enough change going into btrfs that there's a chance that mounting on a system with a newer kernel will prevent mounting on a system with an older kernel. And if you have enough control over kernel versions on all potentially mounting systems to deal with that, then pretty much by definition, you also have enough control over them to hack up a solution that, for instance, looks for a file in specific location on all newly mounted partitions (probably using udev/udisks event hooks), and if found, uses the content of said file as a cue to remount the filesystem with the options found in said file. > I currently don't see how to repair this afterwards without removing the > uncompressed files and writing new ones, which on the other hand spoils > hte memory saving effect of using snapshots instead of copies. A rebalance is the usual way of handling such things, since that rewrites every chunk, taking account of current mount options, etc. If I've been reading correctly, a defrag should handle it now as well, altho that used to break snapshots/cow/reflink-copies, but I /think/ I read that with 3.2 (or was it 3.3-rc1) it doesn't, any more. > It would be much better if there was a way to set options like the > compression option permanently when initially creating the file system, > or later with the btrfs tools. As hinted above, I'd /guess/ the chances of something like that eventually occurring are reasonably high, but there's just too much going on still, to make superblock changes for every little new feature. Better to save them up for one final change before the caution about the on-disk format changes comes off, prioritize the changes then, and do them all at once. Then test the new format for a kernel cycle or two just to be sure, and remove the format change boilerplate the cycle after that. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
