Re: GPT vs BSD-label
On Tue, Feb 09, 2016 at 12:36:59AM +, Christos Zoulas wrote: > > OpenBSD has done it. I've made the same code changes but I stopped > just before committing because we have dozens of custom copies of disklabel > code that would need to be adjusted and tested. > You also need to keep in mind that OpenBSD don't give a flying fsck about doing multi-boot. When I updated my laptop a couple of years ago the system recovery insisted on using GPT (to the extent that it *must* be laid out exactly how they expect[1]), since I wanted windows on there I needed to work with that. GPT is the way the PC hardware is going, ignoring that direction is just going to result in pain further down the track. I have been using GPT + wedges + cgd for a couple of years, it works fine. [1] I had to resort to letting it install windows, then immediately shrink the windows partition so I could create partitions for linux and NetBSD. I have windows 8, fedora core and NetBSD all coexisting using grub2 as the boot selector. -- Brett Lymn Let go, or be dragged - Zen proverb.
Re: GPT vs BSD-label
swiftgri...@gmail.com (Swift Griggs) writes: >/dev/sda1 vs /dev/sd1a >So, they use letters first, then numbers. Actually that gets more and more unusuable in Linux. You need to access disks as /dev/disk/by-/YY and partitions with something like /dev/disk/by-/YY-part1 and you have several alternate paths to the same disk. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: GPT vs BSD-label
On Tue, 9 Feb 2016, Christos Zoulas wrote: OpenBSD has done it. I've made the same code changes but I stopped just before committing because we have dozens of custom copies of disklabel code that would need to be adjusted and tested. Well, not like I have any authority, but I'd welcome that change. I can learn to love GPT at some point, too. It's just a bit different. However, there is still some functionality that comes with labels that seems needed above and beyond what a simple partition table will do. Ie.. things like the 'overlap' partitions. Of course, the way Linux does it also works, but if you think about it, it's the same as the BSD system in reverse ie.. /dev/sda1 vs /dev/sd1a So, they use letters first, then numbers. When they run out of letters Linux doubles them up: /dev/sdaa1 I'm not sure there are applications where folks want to make more than 26 total slices on a disk, but maybe someone knows of one. Since in BSD, the disc names are ordinal, that's not going to be a problem. They can just number off till the end of time (or their buffer, whichever comes first). Anyhow, it sounds like GPT is the short answer, and BSD disklabels still have some mindshare and it's possible they will also see some enhancement (I'm hoping). I will certainly be willing to test on i386, AMD64, SGIMIPS, and SPARC platforms. I'll have Amiga 68k going soon as well, but I won't have any huge disks to test with on the A68k platform. Anyhow, I guess there is probably also work to do in other areas like RAID Frame and LVM to make sure they can cope with any changes to the disklabel code. Hopefully, most of that is abstracted in library calls. -Swift
Re: GPT vs BSD-label
On 2016-02-09 00:41, John Nemeth wrote: Those problems could be solved. Obviously, old tools wouldn't work with the new format; however, new tools could work with either format. But, the first issue is that it is an on-disk format. You need to find the space to expand the disklabel and do so in a manner that doesn't break anything. As demonstrated by OpenBSD, supposedly, this is possible (I have not examined it in any depth to assure myself that it doesn't break anything; I am simply aware of it). I would actually prefer if NetBSD would do as OpenBSD, and keep and extend disklabels... But then again, I think I disagree with too much of the direction of NetBSD these days to ever think I'll be happy anyway. Keep in mind, that I am definitely not an advocate of change for the sake of change, but if there is a need or a clear advantage then yes. In this case, the need was is obvious, the limitations of the format bumping up against newer drives. The other need was to keep up and be usable on modern PCs and certain other systems. Right now, most systems still have a Compatibility Support Module, but the day will come when you work with the modern stuff, or you don't work at all. Are you essentially saying that non-modern machines (essentially non x86-64) are also destined to become unsupported? Are we really trying that much to become Linux? BTW, disklabels were released with 4.3BSD-Tahoe, which was released in June 1988 (28 years ago). There were plenty of versions of BSD prior to that which didn't support disklabel. The first release of BSD was in 1977, so it took 11 years for disklabel to come about. In 1988, an 80MB HD would have been huge and probably not available for the type of machines that BSD ran on. With 80MB HDs, you would need 25,000 of them to make 2TB, which means 2TB was unfathomable. Given the constraints of the time, disklabel was a reasonable format. However, time tends to blow away all constraints. True. Disklabels are somewhat "modern". But it's not like it was a big change. Before the disklabels, you had the partition table in the device driver, and you had details needed for creating file systems in /etc/dtab (I think it was). Disklabels just was a natural evolution to this, where you stopped having fixed partition sizes for each type of device. It's pretty much the same information was there before and after. Disklabels just moved where the information was located. And in 1988, 80MB wasn't that big. You had way larger drives available. RP06 was at 176MB, and was available many years before that, as was several other large Massbus disks. In fact, in 1988, DEC introduced the RA90, at 1.2G. But yes, what seemed huge back then, are small now. So it's nothing strange that some fields have started to feel small... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: GPT vs BSD-label
Date:Mon, 8 Feb 2016 15:41:41 -0800 From:John Nemeth Message-ID: <201602082342.u18Ngfw5029915@server> [Caution: crappy kre memory dump below... treat it as random gibberish...] | The first release of BSD was in 1977, That's true, but hardly relevant, BSD1 was not any kind of complete OS, it was a set of utilities (and some patches) that you applied to an existing system (this one was to 6th edn unix). 2BSD was the same, just contained more (I mean the original 2BSD, not the 2.n systems that came after 4BSD which were BSD system retro-fits to pdp-11's) The first complete (as in bootable as it came) BSD was 3BSD (late 1979?) | In 1988, an 80MB HD would have been huge and probably | not available for the type of machines that BSD ran on. That's about a decade out - might have been true (just) in 1978 perhaps, but expensive 300MB drives (RP06?), and then (much cheaper) Eagles (320MB) came in the fairly early 80's - I suspect RP06's were probably supported in 7th edition for pdp11's and 32V for vaxen, both of which preceded 3BSD - after which disc sizes stagnated for years. By 1988 though, I think the first 600MB and GB drives would have been around, and ever since things have just grown. | which means 2TB was unfathomable. But that was certainly true. A system with a couple of GB (total, usually spread over several drives, and without any kind of raid/ccd/lvm to aggregate them) would have been considered very well endowed indeed. 1000 times as much - absurd! | Given the constraints of the time, disklabel | was a reasonable format. However, time tends to blow away all | constraints. Agreed, it is time for disklabel to (gradually) die away, just expanding it to 64 bit numbers makes little sense - it is still a whole new format, but still suffers from other limitations (like having to fit in a sector), GPT is kind of overblown, but it is what is being used these days, and it has the potential to support everything for a very long time, and is certainly very flexible). There's no point invention something different just so we can be different, just use GPT, there's nothing fundamentally wrong with it. kre
Re: GPT vs BSD-label
On 2016-02-08 21:30, Swift Griggs wrote: > Can one use the BSD disklabel to fully replace a GPT or MBR table? I > understand why folks want to move from MBR to GPT, but do the same > reasons apply to BSD disklabels? In other words, is there any advantage > to using GPT over BSD diskabels ? > The only thing I can think of is that the partitions might be visible to > other OS's which aren't savvy about BSD disklabels. In my case, there is > no value in that as my disks stay with BSD machines. My experience with NetBSD and FreeBSD is that one can't read the other's disklabels. Also, when I tried to disklabel-partition a NetBSD slice, and write the result, it didn't seem to hold. However, when I ran sysinst, the disklabel held. So now I have nothing further to do with BSD disklabels. Also, GPT enables me to not worry about running short of primary partitions. Tom
Re: GPT vs BSD-label
John Nemeth writes: > BTW, disklabels were released with 4.3BSD-Tahoe, which was > released in June 1988 (28 years ago). There were plenty of versions > of BSD prior to that which didn't support disklabel. The first > release of BSD was in 1977, so it took 11 years for disklabel to > come about. In 1988, an 80MB HD would have been huge and probably > not available for the type of machines that BSD ran on. With 80MB This is a memory lane trip. In 1988, I was using a MicroVax II, and I think it had 8 MB of RAM and 80 MB would have been about right for disk, but maybe it was 40 MB. IIRC this machine cost about $2. I dimly remember a 320 MB drive coming with the MicroVax III that arrived around 1990. But regardless of such nits, you are totally correct about the orders of magnitude between the disks of the time and the disklabel limit. > HDs, you would need 25,000 of them to make 2TB, which means 2TB > was unfathomable. Given the constraints of the time, disklabel > was a reasonable format. However, time tends to blow away all > constraints. I at first reacted that you couldn't be right about disklabels because I think I remember that a Sixth Edition system I used in 1977 had multiple partitions, of the familiar a/b/d/e layout that we use today. This was on an RK05 that was 2.5MB for each of two disk drives. But then I remembered that the partition tables were *compiled into the kernel* and that's why disklabels were such a huge step forward. signature.asc Description: PGP signature
Re: GPT vs BSD-label
In article <201602082342.u18Ngfw5029915@server>, John Nemeth wrote: >On Feb 8, 3:02pm, Swift Griggs wrote: >} On Mon, 8 Feb 2016, John Nemeth wrote: >} > Standard BSD disklabels have the same limitation as MBRs as they use >} > 32-bit numbers for partition start and size. >} >} I take it that there is more to it than that... ? I'm sure I'm >} over-simplifying, but simply changing the long to a int64_t I suppose has >} greater impact and implications for other tools and code that read >} disklabels, right ? > > Those problems could be solved. Obviously, old tools wouldn't >work with the new format; however, new tools could work with either >format. But, the first issue is that it is an on-disk format. >You need to find the space to expand the disklabel and do so in a >manner that doesn't break anything. As demonstrated by OpenBSD, >supposedly, this is possible (I have not examined it in any depth >to assure myself that it doesn't break anything; I am simply aware >of it). OpenBSD has done it. I've made the same code changes but I stopped just before committing because we have dozens of custom copies of disklabel code that would need to be adjusted and tested. christos
Re: GPT vs BSD-label
This will give you some insight about the pains of trying to use disklabel on larger disks. However If you add another drive later, I see no reason why it couldn't be gpt, and the current one mbr. - Original Message - From: Swift Griggs To: netbsd-users@netbsd.org Sent: Monday, February 8, 2016 5:02 PM Subject: Re: GPT vs BSD-label On Mon, 8 Feb 2016, John Nemeth wrote: > Standard BSD disklabels have the same limitation as MBRs as they use > 32-bit numbers for partition start and size. I take it that there is more to it than that... ? I'm sure I'm over-simplifying, but simply changing the long to a int64_t I suppose has greater impact and implications for other tools and code that read disklabels, right ? I'm sure you see where I'm going. I'm just basically thinking that I have no need for GPT partition tables on systems that will never run anything but NetBSD. The only concern is losing capacity or the ability to get at future capacity. Your point about 6TB disks is spot-on. However, disk slices are fundemental to BSD and it's tools, so I figured I do an experiment with "nothing but what I need". I find GPT's tail-backup annoying anyway. Thanks, Swift
Re: GPT vs BSD-label
This will give you some insight about the pains of trying to use disklabel on larger disks. However If you add another drive later, I see no reason why it couldn't be gpt, and the current one mbr. https://wiki.netbsd.org/users/mlelstv/using-large-disks/ - Original Message - From: Darren To: Swift Griggs ; NetBSD User Maillist Sent: Monday, February 8, 2016 5:30 PM Subject: Re: GPT vs BSD-label This will give you some insight about the pains of trying to use disklabel on larger disks. However If you add another drive later, I see no reason why it couldn't be gpt, and the current one mbr. - Original Message - From: Swift Griggs To: netbsd-users@netbsd.org Sent: Monday, February 8, 2016 5:02 PM Subject: Re: GPT vs BSD-label On Mon, 8 Feb 2016, John Nemeth wrote: > Standard BSD disklabels have the same limitation as MBRs as they use > 32-bit numbers for partition start and size. I take it that there is more to it than that... ? I'm sure I'm over-simplifying, but simply changing the long to a int64_t I suppose has greater impact and implications for other tools and code that read disklabels, right ? I'm sure you see where I'm going. I'm just basically thinking that I have no need for GPT partition tables on systems that will never run anything but NetBSD. The only concern is losing capacity or the ability to get at future capacity. Your point about 6TB disks is spot-on. However, disk slices are fundemental to BSD and it's tools, so I figured I do an experiment with "nothing but what I need". I find GPT's tail-backup annoying anyway. Thanks, Swift
Re: GPT vs BSD-label
On Feb 8, 3:02pm, Swift Griggs wrote: } On Mon, 8 Feb 2016, John Nemeth wrote: } > Standard BSD disklabels have the same limitation as MBRs as they use } > 32-bit numbers for partition start and size. } } I take it that there is more to it than that... ? I'm sure I'm } over-simplifying, but simply changing the long to a int64_t I suppose has } greater impact and implications for other tools and code that read } disklabels, right ? Those problems could be solved. Obviously, old tools wouldn't work with the new format; however, new tools could work with either format. But, the first issue is that it is an on-disk format. You need to find the space to expand the disklabel and do so in a manner that doesn't break anything. As demonstrated by OpenBSD, supposedly, this is possible (I have not examined it in any depth to assure myself that it doesn't break anything; I am simply aware of it). } I'm sure you see where I'm going. I'm just basically thinking that I have } no need for GPT partition tables on systems that will never run anything } but NetBSD. The only concern is losing capacity or the ability to get at Slowly, but surely, that is the way that NetBSD is moving, at least on system where that will be the norm. } future capacity. Your point about 6TB disks is spot-on. However, disk } slices are fundemental to BSD and it's tools, so I figured I do an So are many other things that seemed like a great idea 40 years ago, but times change. Some of those things are still good ideas, some are not. } experiment with "nothing but what I need". I find GPT's tail-backup } annoying anyway. I consider it a feature. Loss/corruption of sectors at the beginning of a disk isn't totally uncommon. Having a quick and easy way of recovering a disk is quite useful. One just needs to be aware of it and what they are doing with respect to it. It's a learning curve, but so were disklabels at one time. Keep in mind, that I am definitely not an advocate of change for the sake of change, but if there is a need or a clear advantage then yes. In this case, the need was is obvious, the limitations of the format bumping up against newer drives. The other need was to keep up and be usable on modern PCs and certain other systems. Right now, most systems still have a Compatibility Support Module, but the day will come when you work with the modern stuff, or you don't work at all. BTW, disklabels were released with 4.3BSD-Tahoe, which was released in June 1988 (28 years ago). There were plenty of versions of BSD prior to that which didn't support disklabel. The first release of BSD was in 1977, so it took 11 years for disklabel to come about. In 1988, an 80MB HD would have been huge and probably not available for the type of machines that BSD ran on. With 80MB HDs, you would need 25,000 of them to make 2TB, which means 2TB was unfathomable. Given the constraints of the time, disklabel was a reasonable format. However, time tends to blow away all constraints. }-- End of excerpt from Swift Griggs
Re: GPT vs BSD-label
On Mon, 8 Feb 2016, John Nemeth wrote: Standard BSD disklabels have the same limitation as MBRs as they use 32-bit numbers for partition start and size. I take it that there is more to it than that... ? I'm sure I'm over-simplifying, but simply changing the long to a int64_t I suppose has greater impact and implications for other tools and code that read disklabels, right ? I'm sure you see where I'm going. I'm just basically thinking that I have no need for GPT partition tables on systems that will never run anything but NetBSD. The only concern is losing capacity or the ability to get at future capacity. Your point about 6TB disks is spot-on. However, disk slices are fundemental to BSD and it's tools, so I figured I do an experiment with "nothing but what I need". I find GPT's tail-backup annoying anyway. Thanks, Swift
Re: GPT vs BSD-label
On Feb 8, 1:30pm, Swift Griggs wrote: } } Can one use the BSD disklabel to fully replace a GPT or MBR table? I } understand why folks want to move from MBR to GPT, but do the same reasons } apply to BSD disklabels? In other words, is there any advantage to using } GPT over BSD diskabels ? Standard BSD disklabels have the same limitation as MBRs as they use 32-bit numbers for partition start and size. This means that they have a 2TB size limit. In theory, this could be worked around by using a larger sector size, i.e. using a newer disk that has a 4KB sector size in native mode. That would take you to 16TB. However, given that you can buy 6TB drives off the shelf today, that's not much better (four drives in a RAID5 array would put you over that limit). I will note that the people over at OpenBSD have done something to extend disklabel to use 64-bit numbers. However, as far as I know, they are the only ones going that route. Also, their GPT implementation is a strange hybrid, where they bury an OpenBSD disklabel and all partitions inside a single GPT partition. In other words, they treat GPT the same way that everybody else does MBR. As far as I know, they are the only ones that have chosen that route, which makes their disks incompatible with everything else. } The only thing I can think of is that the partitions might be visible to } other OS's which aren't savvy about BSD disklabels. In my case, there is } no value in that as my disks stay with BSD machines. In theory you can put a BSD disklabel at the beginning of a disk and skip the MBR. Note that there are some poorly written BIOSes that will get upset at this. It is something that I have done in the past. However, I find that the hassle of using a "non-standard" configuration is just not worth it, especially when you consider that you can't even buy anything smaller then 100GB, and you'll only save 1MB or less. Before, various people jump in, I'll point out that none of the above applies to people using unusual/obscure/ancient hardware. }-- End of excerpt from Swift Griggs
Re: GPT vs BSD-label
On 2016-02-08 21:30, Swift Griggs wrote: Can one use the BSD disklabel to fully replace a GPT or MBR table? I understand why folks want to move from MBR to GPT, but do the same reasons apply to BSD disklabels? In other words, is there any advantage to using GPT over BSD diskabels ? The only thing I can think of is that the partitions might be visible to other OS's which aren't savvy about BSD disklabels. In my case, there is no value in that as my disks stay with BSD machines. I think there might be a size limitation in the BSD disklabel, which have been raised in GPT. But apart from that, nah. I only use BSD disklabels myself. I also run on machines that have never hear of MBR, and all of my disk is the C partition! Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
