Re: Is it time to dump disklabel and use GPT instead?
On Wed, Jul 28, 2010 at 01:00:37PM -0500, Chris Turner wrote: elekktrett...@exemail.com.au wrote: that is incompatible with everything else on the market. You're not going to get Linux to change because of BSD, it's the other way around. At least man socket() LoL :-)
Re: Is it time to dump disklabel and use GPT instead?
Yes, it's students-only. Don't wait! Start now. It'll be difficult, but nothing worthwhile is ever easy. So I have to be a uni student or something like that? Petr
Re: DragonflyBSD GEOM? (Re: Is it time to dump disklabel and use GPT instead?)
If someone wants to write a really nice gpt partition editor that pops you into vi or emacs or whatever then I would be more amendable to using gpt as a default. But if all we have is command-line list/add/remove junk, then no. Can you give me some pointers as for where to start looking for more information on our implementation of GPT? How much low level stuff is involved in writing such an editor? Petr
Re: DragonflyBSD GEOM? (Re: Is it time to dump disklabel and use GPT instead?)
: If someone wants to write a really nice gpt partition editor that : pops you into vi or emacs or whatever then I would be more amendable : to using gpt as a default. But if all we have is command-line : list/add/remove junk, then no. : :Can you give me some pointers as for where to start looking for more :information on our implementation of GPT? How much low level stuff is :involved in writing such an editor? : :Petr The kernel understands gpt partitions. The boot code does not. The userland tools are the old FreeBSD tools, in /usr/src/sbin/gpt. GPT based projects can be broken down as follows: For the gpt tool: * Add an editor feature to the gpt tool that lays out existing partitions and allows new ones to be specified, similar to how disklabel -e works now. * Implement super sector alignment and implement silent skipping of the small gap areas created between partitions when super sector alignment is done. For the boot code: gpt with a compat mbr replaces fdisk entirely. Add a version of the boot0 code that can find the boot partition. Another option here is to hardwire the offset in and have gpt figure it out and update it in-place, which might be needed for boot0. A gtp-aware boot1/boot2 is then needed, and probably also a gpt-aware loader. I expect a good chunk of this could be ported from FreeBSD. For native GPT booting (non compat MBR booting) ... I don't know much about that, but it would be a separate sub-project. -Matt Matthew Dillon dil...@backplane.com
Re: Is it time to dump disklabel and use GPT instead?
On Thu, July 29, 2010 7:56 pm, elekktrett...@exemail.com.au wrote: Yes, it's students-only. Don't wait! Start now. It'll be difficult, but nothing worthwhile is ever easy. So I have to be a uni student or something like that? Yes. http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#student_eligibility Given that's it's going to be a year until the next one, I wouldn't wait on any work you may want to do; a new GPT editor could be finished in less time, I would guess.
Re: Is it time to dump disklabel and use GPT instead?
Given that's it's going to be a year until the next one, I wouldn't wait on any work you may want to do; a new GPT editor could be finished in less time, I would guess. Doah, I haven't been a student for 5 years :)
Re: Is it time to dump disklabel and use GPT instead?
On 28/07/10 03:30, Adam Vande More wrote: [...] although I am curious to know why GEOM wasn't chosen. It's both more powerful, and easier to use IMO. Some examples of that would be gmirror, glabel, gstripe, HAST, etc -- all easier than the Linux equivalents. The mdadm stuff is reliable, but a real PITA. For me anyways, including more GPL tools is a turnoff. This is getting hugely off-topic, but here go my reasons for preferring to stay away from geom. Just a side note first: mdadm and md-raid do not use device mapper, they use their own in-kernel stuff. Now my opinion on why geom is not the way to go but dm is can be summarized in the following points: - geom is NOT easier to use from a developer's perspective. Device Mapper targets are, imo, much easier to write. - geom forces all the I/O onto one (or two?) threads that transport it across a hugely complicated system. IMO this won't scale well in the future, when the bottleneck moves away from the disks (as already is starting to be the case with SSDs) - We don't need to reinvent the wheel. We have good MBR, disklabel and decent but improvable GPT support already in our disk subsystem. - geom wants to do everything in kernel-land while device mapper devices usually rely on a userland configuration program that reads and parses metadata. This is *much* more flexible than having to implement huge parsers in kernel-land, such as the one required for lvm, just to name one. - Device Mapper offers compatibility with Linux, the most used non-windows operating system afaik. And as a matter of fact we were talking about Linux users here, so they would definitely have much more issues with geom. [...] If GEOM where to be completed, gpart should be useable too then only the boot bits need to be solved. We already have GPT support in the kernel, and gpart would offer no advantage that I know of. The support everyone else is talking about is GPT support in the loader. Cheers, Alex Hornung
DragonflyBSD GEOM? (Re: Is it time to dump disklabel and use GPT instead?)
On Wed, Jul 28, 2010 at 2:13 AM, Alex Hornung ahorn...@gmail.com wrote: On 28/07/10 03:30, Adam Vande More wrote: [...] although I am curious to know why GEOM wasn't chosen. It's both more powerful, and easier to use IMO. Some examples of that would be gmirror, glabel, gstripe, HAST, etc -- all easier than the Linux equivalents. The mdadm stuff is reliable, but a real PITA. For me anyways, including more GPL tools is a turnoff. This is getting hugely off-topic, but here go my reasons for preferring to stay away from geom. Perhaps, I'll start a new thread. Just a side note first: mdadm and md-raid do not use device mapper, they use their own in-kernel stuff. Now my opinion on why geom is not the way to go but dm is can be summarized in the following points: I know, my point for that is the geom raid modules are so much easier to setup and manage from an administration perspective. DragonBSD software raid would benifit a great deal here. - geom forces all the I/O onto one (or two?) threads that transport it across a hugely complicated system. IMO this won't scale well in the future, when the bottleneck moves away from the disks (as already is starting to be the case with SSDs) Well it's 3 main actually(up, down, and event threads basically), and depending on the module you can spawn other kernel threads to handle asynchronous stuff to pass off when it's ready. The design has awfully nice performance characteristics like there is a centralized place for bio stuff, optimization would seem to be much easier to implement. You can see evidence of this when using something like gjournal. On gjournaled device, single threaded IO takes a big hit putting it in the Linux realm of performance, however as the threads grow, so does the ability to optimize requests being sent to physical devices. That's why gjournal devices scale so much better as concurrency grows. I have not observed any performance bottlenecks on my GEOM ssd devices and I have no idea what a theoretical or real-world maximum would be on the GEOM design. - We don't need to reinvent the wheel. We have good MBR, disklabel and decent but improvable GPT support already in our disk subsystem. Like I said in my first post in thread, I don't think abandoning MBR style is good, but defaulting to GPT is desirable on a number of levels including one where different OS's being installed on the disk no longer would have a easy excuse to blow away any partition it finds. - geom wants to do everything in kernel-land while device mapper devices usually rely on a userland configuration program that reads and parses metadata. This is *much* more flexible than having to implement huge parsers in kernel-land, such as the one required for lvm, just to name one. Are you taking about the g_linux_lvm module? I would not consider that huge ~1200 lines. That's tiny compared to what you had to go through to import. Now let's see you write an io scheduler for the new devices. See my point? - Device Mapper offers compatibility with Linux, the most used non-windows operating system afaik. And as a matter of fact we were talking about Linux users here, so they would definitely have much more issues with geom. Perhap they would, hard to say though. If someone is able to learn LVM/DM stuff though, they certainly would be able to GEOM. LVM does have a few advantages over GEOM like being able to resize on the fly, but that functionality does not work here. [...] If GEOM where to be completed, gpart should be useable too then only the boot bits need to be solved. We already have GPT support in the kernel, and gpart would offer no advantage that I know of. The support everyone else is talking about is GPT support in the loader. I know of the differences I guess I didn't relay my whole thought here. gpart was brought up because it's a geom class, and it does have more functionality than the existing D_BSD support(the man page notes there is much to be done). My point is that loader support would also be easier to import if it had the same target, the geom_part_gpt class. -- Adam Vande More
Re: DragonflyBSD GEOM? (Re: Is it time to dump disklabel and use GPT instead?)
On 28 July 2010 17:14, Adam Vande More amvandem...@gmail.com wrote: [...] Well it's 3 main actually(up, down, and event threads basically), and depending on the module you can spawn other kernel threads to handle asynchronous stuff to pass off when it's ready. The design has awfully nice performance characteristics like there is a centralized place for bio stuff, optimization would seem to be much easier to implement. You can see evidence of this when using something like gjournal. On gjournaled device, single threaded IO takes a big hit putting it in the Linux realm of performance, however as the threads grow, so does the ability to optimize requests being sent to physical devices. That's why gjournal devices scale so much better as concurrency grows. I have not observed any performance bottlenecks on my GEOM ssd devices and I have no idea what a theoretical or real-world maximum would be on the GEOM design. I absolutely don't see how forcing the I/O from N different threads onto 2 (events are not I/O effectively) is better than having each I/O maintain (mostly) it's own context. Your particular case may not suffer from any performance impact, but I was mostly talking about a future-proof solution. [...] Are you taking about the g_linux_lvm module? I would not consider that huge ~1200 lines. That's tiny compared to what you had to go through to import. Now let's see you write an io scheduler for the new devices. See my point? I mean every module that needs metadata. From the top of my head I could mention the lvm parser and geli, but I'd suspect most others, too. So GEOM has a lvm parser that is utterly incomplete and obviously offers no management whatsoever. How is that superior to having most of the lvm functionality (in userland), easy to keep up to date and offering the same tools as on Linux? In any case this is not about LVM vs geom since LVM is only one consumer of the device mapper. Now let's see... you write an I/O scheduler on DragonFly... you simply use the dsched framework which fits nicely on top of the disk subsystem. As a matter of fact I could even change dm slightly to use the disk subsystem, too, and hence allow I/O schedulers, mbr, gpt and disklabels on top of dm devices, but I don't think there's much point to it at this time. [...] Perhap they would, hard to say though. If someone is able to learn LVM/DM stuff though, they certainly would be able to GEOM. LVM does have a few advantages over GEOM like being able to resize on the fly, but that functionality does not work here. My point is that there's no need to learn anything new. Also, this is completely subjetive. Maybe you prefer GEOM; I'd argue some of the Linux counterparts are way more intuitive. LVM is only one consumer of device mapper as I said before, so there's really no point in doing this comparison. LVM was imported strictly because of the compatibility with Linux. cryptsetup is another consumer of device mapper, which offers a different interface. My point here is that it's extremely simple to write userland tools to fit anyone's needs. I'm currently working on a mirror target for the device mapper; it'll also have its own userland tool, and not dependent on LVM which you seem to find cumbersome. [...] I know of the differences I guess I didn't relay my whole thought here. gpart was brought up because it's a geom class, and it does have more functionality than the existing D_BSD support(the man page notes there is much to be done). My point is that loader support would also be easier to import if it had the same target, the geom_part_gpt class. I still don't get your point. GPT support in the loader is not assisted in any way by geom or any other similar mess. Cheers, Alex Hornung
Re: Is it time to dump disklabel and use GPT instead?
elekktrett...@exemail.com.au wrote: that is incompatible with everything else on the market. You're not going to get Linux to change because of BSD, it's the other way around. At least man socket()
Re: DragonflyBSD GEOM? (Re: Is it time to dump disklabel and use GPT instead?)
Personally speaking I would prefer the lvm/dm infrastructure. There are many reasons for this, some personal, some not. First of all, we absolutely do not need the duplication. Having both in the system makes no sense whatsoever. It just creates unnecessary confusion. I think that there is just too much logical indirection in geom. I far prefer drive-serno + partition specifications, there is no room for error and no confusion. Logical auto-probing which ignores the serial number is a human error disaster waiting to happen. Also I don't see any advantage to any softraid implementation which requires a full disk sync after a minor glitch, such as someone pulling a plug temporarily or a crash/reboot or a misprobe. It harkens back to issues similar to the background-fsck problem. A production system just can't afford to do 12-36 hours worth of background *anything* after a glitch unless it's the only choice (i.e. a drive actually physically failed and had to be replaced). The majority of glitches are not going to be actual drive failures. -- I don't think gpt vs disklabel really has anything to do with lvm/dm or geom, they are separate issues. If someone wants to write a really nice gpt partition editor that pops you into vi or emacs or whatever then I would be more amendable to using gpt as a default. But if all we have is command-line list/add/remove junk, then no. Even the compat MBR stuff GPT specifies doesn't work generically across all BIOSes, or even most BIOSes. When I was futzing with GPT last year I laid down a compat MBR just exactly the way GPT specified it and my test machine refused to boot. I'll be more amendable once the standard actually works across all new machines and not just on so-called server-class machines. -Matt
Re: DragonflyBSD GEOM? (Re: Is it time to dump disklabel and use GPT instead?)
On Wed, Jul 28, 2010 at 11:39 AM, Alex Hornung ahorn...@gmail.com wrote: I absolutely don't see how forcing the I/O from N different threads onto 2 (events are not I/O effectively) is better than having each I/O maintain (mostly) it's own context. Your particular case may not suffer from any performance impact, but I was mostly talking about a future-proof solution. Here is some detailing of how a geom class can improve performance on multithreaded IO. http://lists.freebsd.org/pipermail/freebsd-geom/2006-June/001290.html http://retis.sssup.it/~fabio/soc09/downloads/D3.pdf Also you look at FreeBSD's sys/geom/eli/g_eli.c for an example implementation for a dedicated thread so as not to pollute the geom up/down threads. Disks can only read/write one thing at a time anyways, and if you have a device with multiple providers, requests can be optimized and split across them. I don't think it's been shown that GEOM is or isn't future-proof. Same with DM. If problems arise in either implementation, I'm sure they would be worked around. I mean every module that needs metadata. From the top of my head I could mention the lvm parser and geli, but I'd suspect most others, too. So GEOM has a lvm parser that is utterly incomplete and obviously offers no management whatsoever. How is that superior to having most of the lvm functionality (in userland), easy to keep up to date and offering the same tools as on Linux? You don't address the GPL part, which is a problem for me and maybe some others. Other BSD's have struggled for a long time removing GPL tools. I also don't understand why having the same tools a Linux is desirable. If that's the goal(eg to attract Linux users) IMO it's misguided. Now let's see... you write an I/O scheduler on DragonFly... you simply use the dsched framework which fits nicely on top of the disk subsystem. As a matter of fact I could even change dm slightly to use the disk subsystem, too, and hence allow I/O schedulers, mbr, gpt and disklabels on top of dm devices, but I don't think there's much point to it at this time. I wasn't aware of dsched, pretty cool. The point remains though as I could list a lot of different modules you couldn't match easily without GEOM. Also not all Linux block stuff is done in userland, eg DRBD. As you point out later this is somewhat subjective, and could easily turn into an pissing match which is not what I want. What I'm mainly looking for is input on importing GEOM, and given your experience any insight would be helpful there. My point is that there's no need to learn anything new. Also, this is completely subjetive. Maybe you prefer GEOM; I'd argue some of the Linux counterparts are way more intuitive. LVM is only one consumer of device mapper as I said before, so there's really no point in doing this comparison. LVM was imported strictly because of the compatibility with Linux. cryptsetup is another consumer of device mapper, which offers a different interface. My point here is that it's extremely simple to write userland tools to fit anyone's needs. I'm currently working on a mirror target for the device mapper; it'll also have its own userland tool, and not dependent on LVM which you seem to find cumbersome. GEOM modules can certianly working in userland, eg ggate, plus it's easily stackable nature and BSD license are other features are what I find attractive. Obviously you and I disagree on the merits of DM/LVM stuff, but if GEOM had been implemented you wouldn't have to write the mirror code. You'd already have well tested, performant code. I still don't get your point. GPT support in the loader is not assisted in any way by geom or any other similar mess. The gpart class is a helper of the loader. It creates the normal gpt boot partition unlike the hack that exists in gpt(8) Also I don't see any advantage to any softraid implementation which requires a full disk sync after a minor glitch, such as someone pulling a plug temporarily or a crash/reboot or a misprobe. The gmirror sync after an unclean disconnect is greatly reduced on gjournal volumes, I haven't timed it lately but it's something like 1 to 2 minutes for TB+ sized volumes. -- Adam Vande More
Re: DragonflyBSD GEOM? (Re: Is it time to dump disklabel and use GPT instead?)
:I still don't get your point. GPT support in the loader is not : assisted in any way by geom or any other similar mess. : : :The gpart class is a helper of the loader. It creates the normal gpt boot :partition unlike the hack that exists in gpt(8) : : :Also I don't see any advantage to any softraid implementation which :requires a full disk sync after a minor glitch, such as someone :pulling a plug temporarily or a crash/reboot or a misprobe. : : :The gmirror sync after an unclean disconnect is greatly reduced on gjournal :volumes, I haven't timed it lately but it's something like 1 to 2 minutes :for TB+ sized volumes. : :-- :Adam Vande More Urm. What's the point of a mirror if you need a third journaling device which itself can fail or glitch? Do you mirror the journal too? I have serious problems with this concept, and also with the complexity and the number of moving parts involved. And what about the massive assumptions being made regarding the survival of on-device write caches, write bandwidth constrictions, the lack of integration with filesystem-derived cache flushes, the duplication of effort when used with filesystems which have their own UNDO/REDO journals? Is there any device stall management? I'll be frank, the FreeBSD stuff is a non-starter for me. If we tried to run something like gmirror and/or gjournal with HAMMER the performance would be abysmal. -Matt
Re: DragonflyBSD GEOM? (Re: Is it time to dump disklabel and use GPT instead?)
On 28/07/10 21:58, Adam Vande More wrote: [...] It's not just that combination though. HammerFS could be used on other modules like gvinum, gconcat, etc, etc. I'm interested in using Dragonfly for some embedded system, but having more GPL stuff is essentially a non-starter for me as well. I really like HammerFS and would have preferred to see that in FreeBSD over ZFS. Just use vinum. It has been there forever and will provide the features you seem to be interested in without the GPL burden. I absolutely fail to see any of your points in why we would want to have geom and I would definitely not welcome having it, for whatever it's worth. If GPL stuff is a non-starter for you, as you put it, then gcc should pose a problem to you as well... Regards, Alex Hornung
Re: Is it time to dump disklabel and use GPT instead?
On 7/24/2010 6:47, elekktrett...@exemail.com.au wrote: It seems that a lot of new comers get a really annoyed(and more than often turn away altogether) with the fact that they have to use archaic programs like disklabel to setup partitions. Wouldn't it be better to simply dump it, and use GPT partitions instead? What evidence do you have of newcomers being more than often turned away by having to use archaic tools? If they want DragonFly only on their whole disk, they can just let the installer install DragonFly to the whole disk without having to use either fdisk or disklabel. If they want DragonFly on part of the disk, they will have to create a partition and have the installer use that. Again, disklabel not needed for installation. I think most users fall in one of the categories above. All in all I think you are really exaggerating here. Regards, Sascha
Re: Is it time to dump disklabel and use GPT instead?
On Tue, Jul 27, 2010 at 7:44 PM, elekktrett...@exemail.com.au wrote: What evidence do you have of newcomers being more than often turned away by having to use archaic tools? I visit a couple of Linux forums, and while the word DragonFly surely seems to have picked up some usage in the recent months, I also hear that they go somewhere else after a brief experience setting it up. Majority of these people seem try DragonFly because of HAMMER and their aim is to setup a backup box. If they want DragonFly only on their whole disk, they can just let the installer install DragonFly to the whole disk without having to use either fdisk or disklabel. From what I hear, people prefer to use a separate hard disk(s) instead of using the one on which they installed DragonFly initially to store their backups. So they cannot avoid fdisk and disklabel. It made me think, what advantage do we get by over-complicating things with disklabels, sectors, offsets etc? They are things that, I feel, majority of *nix users don't wanna hear about these days. I've used *BSD for a few years and while i never really had problems with disklabel(except once), it does seem kind of cool to partition a slice, it is redundant at the same time especially now that GPT is here and it does work with existing BIOSes. I blasted away a DF disklabel by accident once(installing FreeBSD on another slice) and I didnt have backups and I managed to recover my data only partially, sure my fault..i didnt have a backup, but on the other hand I blame the disklabel to be too easy to stuff up. As I mentioned earlier, another issue they seem to find, is the non-availability of choosing BASH during the install. - So, what is the real world advantage of using disklabel, that can't be done with GPT on 99.99% of all OS install? that is worth breaking compatibility with other *BSDs - each BSD implements disklabel differently- and other OSs like Linux - doesn't use disklabel at all but for Linux to support reading/writing to HAMMER or UFS, it would have to implement some basic disklabel support. Petr I am relatively certain nobody is going to argue, your points are mostly valid, and there are others you did not mention. I am also relatively certain nobody is going to stand up and do the work, unless you do. There is finite manpower and to my knowledge existing committers have any number of priorities before even considering GPT. Failing this it is possible someone would make it a priority if there were a reasonable code bounty placed on it. Sam
Re: Is it time to dump disklabel and use GPT instead?
On Tue, Jul 27, 2010 at 8:44 PM, elekktrett...@exemail.com.au wrote: So, what is the real world advantage of using disklabel, that can't be done with GPT on 99.99% of all OS install? that is worth breaking compatibility with other *BSDs - each BSD implements disklabel differently- and other OSs like Linux - doesn't use disklabel at all but for Linux to support reading/writing to HAMMER or UFS, it would have to implement some basic disklabel support. I don't think the last part is true -- presenting block devices is different that the file systems which live on them and I doubt there would be significant roadblocks to creating UFS or HammerFS on the LVM's which have been imported. Also, if Linux wants to import *BSD's block devices, that's a Linux problem, not *BSD's. That being said, FreeBSD's implementation of gpart is quite smooth IMO although there is no installer support yet and as was noted earlier booting from GPT is a new animal. Universally recognizable block devices like gpt creates I think will grow in importance, and I guess that's also part of why LVM made it's way into Dragonfly although I am curious to know why GEOM wasn't chosen. It's both more powerful, and easier to use IMO. Some examples of that would be gmirror, glabel, gstripe, HAST, etc -- all easier than the Linux equivalents. The mdadm stuff is reliable, but a real PITA. For me anyways, including more GPL tools is a turnoff. As said earlier about something else, I'm sure the work will not get done and there are lots of other things to worry about. If someone has the time and knowledge, would you comment on any difficulties there might be importing GEOM? My feeble C skills are woefully inadequate, so it would be nice to have a rough map of what such a project entails, especially the Danger, Will Robinson markers. If GEOM where to be completed, gpart should be useable too then only the boot bits need to be solved. -- Adam Vande More
Re: Is it time to dump disklabel and use GPT instead?
On Tue, July 27, 2010 10:55 pm, elekktrett...@exemail.com.au wrote: Also, if Linux wants to import *BSD's block devices, that's a Linux problem, not *BSD's. I think that some Unix interoperability should be a long term goal for any Unix system. When you have a recognized standard like GPT, using it seems to be the right thing to do, instead of developing another solution that is incompatible with everything else on the market. You're not going to get Linux to change because of BSD, it's the other way around. At least in regards to interoperability. Technical merit, maybe. I might signup for GSoC 2011. Do I have to be a student? Yes, it's students-only. Don't wait! Start now. It'll be difficult, but nothing worthwhile is ever easy.
Re: Is it time to dump disklabel and use GPT instead?
On Tue, Jul 27, 2010 at 9:55 PM, elekktrett...@exemail.com.au wrote: Also, if Linux wants to import *BSD's block devices, that's a Linux problem, not *BSD's. I think that some Unix interoperability should be a long term goal for any Unix system. When you have a recognized standard like GPT, using it seems to be the right thing to do, instead of developing another solution that is incompatible with everything else on the market. I agree, and I'm mostly on your side for making GPT default. You're not going to get Linux to change because of BSD, it's the other way around. At least in regards to interoperability. Technical merit, maybe. I'm not sure I made myself entirely clear. If you implement GEOM, you have the framework in place to use a fully compliant GPT disk which any other vendor could easily read. GEOM has many other modules including one that maps to LVM's, a new io scheduler, and a block based journaling system, etc. -- Adam Vande More
Re: Is it time to dump disklabel and use GPT instead?
: :DragonFly could really lead the way here amongst the BSDs who all use some :version of disklabel. Can DF boot from a GPT partition? If so the next :thing would be teaching it to boot from such a partition without a :disklabel present. : :For example: :/boot ... /dev/da0p0 :/ ... /dev/da0p1 :/usr ... /dev/da0p2 :/var ... /dev/da0p3 : :and so-on. : :Its simple and elegant and will not confuse everyone who is new the BSDs. : :Petr Well, there are two parts to GPT. There is the partition table standard and then there is the BIOS support. If you mean booting from a GPT compatibility slice without needing the BIOS support then it is probably doable. If you mean using the BIOS support API then it gets a lot more difficult. However, our 64-bit disklabel tool is far more advanced then our gpt tool. It has uuids, a 64-bit address space, super-sector alignment, and no slice limit (though the kernel itself implements some practical limits). FreeBSD has a new gpt suite but I have no idea if their partitioning tool was made more convenient (as in throws you into vi and lets you loose). Going to GPT is more a matter of wanting to support multi-boot. I personally have never been keen on multi-boot setups, I don't see much of a point to it other than for playing around. But if someone wants to do the work and can also fix GPT to properly super-sector align partitions then go for it! -Matt Matthew Dillon dil...@backplane.com
Re: Is it time to dump disklabel and use GPT instead?
Well, there are two parts to GPT. There is the partition table standard and then there is the BIOS support. If you mean booting from a GPT compatibility slice without needing the BIOS support then it is probably doable. This. I've come across a few people (Linux users wanting to try DragonFly because of HAMMER) who ultimately go somewhere else because of difficulty to setup partitions(both fdisk and disklabel are difficult to use). Another reason being we don't have BASH in the base which Linux users like. They do get turned off with TCSH, I dont mind it but Im not a Linux user. To setup a HAMMER filesystem requires at least 4 steps: 1) fdisk 2) disklabel 3) newfs_hammer 4) Create PFSs Disklabel seems to be largely redundant to GPT just for the sake of BSDism. Im not in favour of making things more user-friendly just for the sake of it, but this also seems to be a logical step forward. Petr
Is it time to dump disklabel and use GPT instead?
It seems that a lot of new comers get a really annoyed(and more than often turn away altogether) with the fact that they have to use archaic programs like disklabel to setup partitions. Wouldn't it be better to simply dump it, and use GPT partitions instead? Petr
Re: Is it time to dump disklabel and use GPT instead?
On Fri, Jul 23, 2010 at 11:47 PM, elekktrett...@exemail.com.au wrote: It seems that a lot of new comers get a really annoyed(and more than often turn away altogether) with the fact that they have to use archaic programs like disklabel to setup partitions. Wouldn't it be better to simply dump it, and use GPT partitions instead? If by dump it you mean default to GPT style partitioning, I think that is valid discussion. I would say yes, standardization here seems to be a net positive. -- Adam Vande More
Re: Is it time to dump disklabel and use GPT instead?
If by dump it you mean default to GPT style partitioning, I think that is valid discussion. I would say yes, standardization here seems to be a net positive. Yes thats what I mean. Instead of disklabel partitions like ad0s1*, only use GPT partitions ie. ad0p* - note the change from s to p - since calling partitions slices will no longer be necessary as well. Petr
Re: Is it time to dump disklabel and use GPT instead?
DragonFly could really lead the way here amongst the BSDs who all use some version of disklabel. Can DF boot from a GPT partition? If so the next thing would be teaching it to boot from such a partition without a disklabel present. For example: /boot ... /dev/da0p0 / ... /dev/da0p1 /usr ... /dev/da0p2 /var ... /dev/da0p3 and so-on. Its simple and elegant and will not confuse everyone who is new the BSDs. Petr
