-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/31/2014 12:00 AM, Damiön la Bagh wrote: > The 1st 15 mintues of this presentation by the SUN engineers who > wrote ZFS explains the design philosophy behind partitionless > systems (BTRFS/ZFS). If you can find 15 minutes I highly recommend > watching.
Again, there is nothing inherently "partitionless" about btrfs or zfs. You can go without partitions with any filesystem, and no filesystem gets any benefit from not having a partition table. > (other filesystems) The whole point when choosing BTRFS on a setup > is to not use any other file systems. BTRFS/ZFS were designed to > replace all other partitions+filesystems+LVM+RAID schemes (see the > video) No, the idea is to replace lvm and raid layers for dividing up and adding redundancy to storage spaces. In other words, you used to partition a disk into different pieces for different parts of the filesystem, like / and /home, even when they each used the same filesystem type, and you don't want or need to do this with btrfs. A single btrfs partition per disk is not the same thing as not having any partition table at all; do not confuse the two. > (coding in small spaces) The first 64Kib only needs to point to > /@/boot how much code do you really need for a pointer? note: @ > refers to the root subvolume that Ubuntu creates automatically on > an btrfs install. There is no "only points to". That 64k has to have all of the code needed for the grub core, the disk driver, and the btrfs filesystem code, which has to be capable of understanding any btrfs filesystem and locating any file on it. That's a LOT of code for such a complex filesystem. > (UEFI FAT) They didn't need to change MBR they just needed to > change it to a pointer to a place in an existing filesystem (like > the way btrfs works) I think you are confused here again. There are no "pointers". In btrfs, they simply leave the first 64k of the disk untouched so that a boot loader can put itself in the place the pc bios normally loads it from. Blindly loading the first sector of a disk was one of the major design flaws of the pc bios and the reason uefi switched to having an actual filesystem on the disk that the firmware understands and can locate and load files ( that identify which architecture they are for so the correct one can be loaded ) from. The MBR -> GPT switch is really just an added bonus that you may as well take advantage of at the same time you switch to UEFI, but it is actually possible to just use MBR and define an EFI system partition with that. > I checked both my desktop and laptop BTRFS boot drives and they > both show 0x000: EB 63 90 in the very first sector. So I am > guessing the EB 63 90 represents BTRFS's boot pointer area. Again, there is no pointer. The first 440 bytes of the mbr/boot sector are executable 16 bit 8086 code. The first instruction of which is usually a jump instruction. EB 63 90 decodes to JMP 0165. You are looking at the first instruction of grub. The grub code goes on to read the rest of itself from that first 64k, then on to opening the filesystem, loading modules, the config file, etc. > (wipe btrfs boot sector) I'll try your experiment in a VM tomorrow > (am on nightshift now and want to have my mind clear and focused > when I'm wiping sectors) This did spark me to do some more > research. Apparently there is a utility to remove ZFS/BTRFS from a > physical disk that is prefered over dd and doesn't have to destroy > all of your data. wipefs. > https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#How_to_clean_up_old_superblock_.3F wipefs > is for removing signatures of any kind of filesystem, partition table, raid, etc. This will remove the actual btrfs superblock ( at offset 64k ), not the grub boot sector, so you don't want to do that. The idea is to leave your filesystem intact, and just remove the grub boot sector. > Thank you from the bottom of my heart! Your software has helped me > and my colleagues in numerous ways over the years. Thank you for > making something so robust and easy to use. I've made donations to > the gParted project in the past, I'd like to make another > donation, is there a page for parted separately or are gParted and > parted developed together? Well, I'm not the one guy who wrote parted; just the current maintainer. I have done quite a bit of work improving it ( and some on gparted ) these last two years. parted itself does not have any sort of donation setup, but it is a GNU project so you could donate to GNU. gparted is a separate project that uses the libparted library. There is a bit of cross pollination though as I have contributed plenty of patches to gparted, and Mike Fleetwood, who is one of the major gparted developers, recently contributed a patch to fix a bug in parted. > (parted feature req) where is the best place to add feature > requests for parted? I've been secretly hoping that parted would > one day shdisplay LVM volume groups and logical volumes, and would > display BTRFS/ZFS subvolumes in a similar fashion to how MSDOS > extended partitions are currently shown. I've had a similar thought but decided it simply isn't workable within the current framework. The whole system assumes it is dealing with contiguous slices of a single drive. Dealing with non contiguous slices that can span multiple drives gets real hairy real fast, and you can't really represent it in a sensible way. For instance, you may have two btrfs subvolumes. The first subvolume may occupy bytes 1-a, then b-c. In between a and b may be used by a second subvolume. In fact, parts of the a-b range may be *shared* between the two subvolumes, so how do you show that? What if you have a dozen snapshots? 90% of their space is shared, but each one has 5% unique to itself. It really just gets impossible to visualize. There was a btrfs-gui tool posted a few years back to the mailing list that let you visualize just the chunk map: a-b space on disk one is linear, b-c on disk one and d-e on disk two are a mirror, and so on. Even that granularity was somewhat complicated. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUU5cbAAoJEI5FoCIzSKrwlAQIAJCbv7w63P52ecqASEjSY/SL lDDMw7Xwr+nepJxpLbG11Q01bAk6hZR1KhTYySwXPHs+PoXzWRZD2CJ3SkAAXXdg AuG8I5DD+KPyhZE2sSYZdOhfuEzinonSik2MXiQgelQxDNvo1YvzG/Iabdsmd8Y0 jsVQbeb4is7uPOvdrJpC/oVt0xBf6bNQ5OWcNC2FojPHhu1MM8es7/d3xORy7gPh u5nIX5JnMSI4NyQtnN9ZX2w6LyrN1YbugeFASznqg9zdhnn0JtOP94bPTZhygTmn 0ZtMDaVqwlQCViMZJ3q7I/btRmHuBk7COy0PcWmCEz1sWA2diKVOrA08G5kU6p0= =Yw2M -----END PGP SIGNATURE----- -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1383948 Title: Ubiquity Installer doesn't recognize existing btrfs partitions To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1383948/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
