Description of problem: XFS and ext4 can both set the UUID. This is critical for management software that needs to *pick* and track a particular filesystem by UUID. It's also useful for other use cases like migrating filesystems, etc... Eg: xfs_admin -U <UUID> mkfs.ext4 -U <UUID> It's not clear how to do this in btrfs. Either at filesystem creation time, or as an operation that happens after the fact. Setting this at creation time would be sufficient. Version-Release number of selected component (if applicable): 20+ How reproducible: 100% Steps to Reproduce: 1. Try to set UUID. 2. Currently not possible. 3. Actual results: UUID is generated randomly. Expected results: Would like to pick a particular UUID. Additional info: Any work arounds to set a particular UUID would be appreciated!! Thanks!
btrfs-progs-3.14.1 has been pushed to Fedora 19 and 20 for testing. I frankly have no idea if this will resolve your bug or not, but if you test it and find that it does, please take the opportunity to close this bug. :) Thanks, -Eric
(In reply to Eric Sandeen from comment #1) > btrfs-progs-3.14.1 has been pushed to Fedora 19 and 20 for testing. > > I frankly have no idea if this will resolve your bug or not, but if you test > it and find that it does, please take the opportunity to close this bug. :) > > Thanks, > -Eric Thanks for the thought Eric, but I don't think it will. Cheers!
yeah, sorry, that was just a mass update. Somebody should write a patch ... o_O
(In reply to Eric Sandeen from comment #3) > yeah, sorry, that was just a mass update. Oh cool, clever. I hope you're not a bot :) > Somebody should write a patch ... > o_O Actually, I would love this. I expect it might require some kernel bits too. I really don't know. Do you think you could ask someone with the btrfs know-how? I'm not sure who that is. Thanks!
Oh, ok - so, checking with Zach, the UUID is in every metadata block on the filesystem. Changing the UUID after the fs has been populated is decidedly nontrivial, because of that. It's _everywhere_ # blkid fsfile fsfile: UUID="87642f76-977a-4eb5-99b6-9b5e961bcdc3" UUID_SUB="4b2f70c4-e35c-44ac-92ae-0c54d53b696e" TYPE="btrfs" # hexdump -C fsfile | grep "87 64 2f 76 97 7a 4e b5 99 b6 9b 5e 96 1b cd c3" | wc -l 844 and that's just for a filesystem populated with an e2fsprogs tree...
(In reply to Eric Sandeen from comment #5) > Oh, ok - so, checking with Zach, the UUID is in every metadata block on the > filesystem. > > Changing the UUID after the fs has been populated is decidedly nontrivial, > because of that. It's _everywhere_ > > # blkid fsfile > fsfile: UUID="87642f76-977a-4eb5-99b6-9b5e961bcdc3" > UUID_SUB="4b2f70c4-e35c-44ac-92ae-0c54d53b696e" TYPE="btrfs" > > # hexdump -C fsfile | grep "87 64 2f 76 97 7a 4e b5 99 b6 9b 5e 96 1b cd > c3" | wc -l > 844 > > and that's just for a filesystem populated with an e2fsprogs tree... So I feared something like that, which is why I mentioned that "Setting this at creation time would be sufficient." ... Since internally there's probably some kernel equivalent to `uuidgen`, they should (if there isn't already) be a way to choose what UUID instead of using the random one... Which is the feature I need. Hopefully it exists, or is an easy patch that someone with kernel magic powers can look into. Thanks again :)
Oh, yeah, doing it at creation time should be trivial. Sorry I missed that. But is that really useful? If so I can probably hack up the patch. I just didn't think that was a thing anyone would need...
(In reply to Eric Sandeen from comment #7) > Oh, yeah, doing it at creation time should be trivial. Sorry I missed that. Please don't be sorry :) > But is that really useful? If so I can probably hack up the patch. I just > didn't think that was a thing anyone would need... Oh yeah, it would be especially useful!! (IMO) anyways. I can obviously refer you to my specific use case, but I'm sure if we dug around in the archives of why ext4 or xfs did it, then we'd probably find even better examples. This type of patch is probably worth a few $beverages from my personal account, or more if I can find a willing/unsuspecting manager to cover them :)
In that case I am all over it. ;)
# ./mkfs.btrfs -U 12345678-abdc-1234-1234-123456789abc fsfile ... # blkid fsfile fsfile: UUID="12345678-abdc-1234-1234-123456789abc" UUID_SUB="2895068e-a437-4e30-b121-df7c1b0a7ee9" TYPE="btrfs" Hoppy, please. ;) I'll send the patch upstream.
(In reply to Eric Sandeen from comment #11) > # ./mkfs.btrfs -U 12345678-abdc-1234-1234-123456789abc fsfile > > ... > > # blkid fsfile > fsfile: UUID="12345678-abdc-1234-1234-123456789abc" > UUID_SUB="2895068e-a437-4e30-b121-df7c1b0a7ee9" TYPE="btrfs" > > Hoppy, please. ;) > > I'll send the patch upstream. Done already? Sweet. Can you point me to the sha1?
Not committed yet, I'll cc: you on the patch.
It's in kdave's integration tree now, so Chris should pull it into the main repo at some point. It took more discussion than I expected. :) http://repo.or.cz/w/btrfs-progs-unstable/devel.git/commitdiff/a03901849f868c65f845325fcaeb3d25c6896759 -Eric
btrfs-progs-3.14.2-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/btrfs-progs-3.14.2-3.fc20
Package btrfs-progs-3.14.2-3.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing btrfs-progs-3.14.2-3.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7440/btrfs-progs-3.14.2-3.fc20 then log in and leave karma (feedback).
btrfs-progs-3.14.2-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.