Re: More than 16 partitions
On Sat, Apr 25, 2020 at 2:41 PM Theo de Raadt wrote: > > Amelia A Lewis wrote: > > > So, and I recognize that the answer might reasonably be "go read more > > code and figure it out yourself," a question for Theo and others if you > > have a moment: why couldn't an arch expand past sixteen? It seems, both > > from the math calculating struct size (which may be mistaken, in which > > case I apologize) and in the comment for MAXMAXPARTITIONS that more > > *are* possible. > > Because there is another reason. Here are the device nodes for > two sequentially-numbered disks. > > brw-r- 1 root operator4, 0 Apr 17 11:50 sd0a > brw-r- 1 root operator4, 1 Apr 17 11:50 sd0b > brw-r- 1 root operator4, 2 Apr 17 11:50 sd0c > brw-r- 1 root operator4, 3 Apr 17 11:50 sd0d > brw-r- 1 root operator4, 4 Apr 17 11:50 sd0e > brw-r- 1 root operator4, 5 Apr 17 11:50 sd0f > brw-r- 1 root operator4, 6 Apr 17 11:50 sd0g > brw-r- 1 root operator4, 7 Apr 17 11:50 sd0h > brw-r- 1 root operator4, 8 Apr 17 11:50 sd0i > brw-r- 1 root operator4, 9 Apr 17 11:50 sd0j > brw-r- 1 root operator4, 10 Apr 17 11:50 sd0k > brw-r- 1 root operator4, 11 Apr 17 11:50 sd0l > brw-r- 1 root operator4, 12 Apr 17 11:50 sd0m > brw-r- 1 root operator4, 13 Apr 17 11:50 sd0n > brw-r- 1 root operator4, 14 Apr 17 11:50 sd0o > brw-r- 1 root operator4, 15 Apr 17 11:50 sd0p > brw-r- 1 root operator4, 16 Apr 17 11:50 sd1a > brw-r- 1 root operator4, 17 Apr 17 11:50 sd1b > brw-r- 1 root operator4, 18 Apr 17 11:50 sd1c > brw-r- 1 root operator4, 19 Apr 17 11:50 sd1d > brw-r- 1 root operator4, 20 Apr 17 11:50 sd1e > brw-r- 1 root operator4, 21 Apr 17 11:50 sd1f > brw-r- 1 root operator4, 22 Apr 17 11:50 sd1g > brw-r- 1 root operator4, 23 Apr 17 11:50 sd1h > brw-r- 1 root operator4, 24 Apr 17 11:50 sd1i > brw-r- 1 root operator4, 25 Apr 17 11:50 sd1j > brw-r- 1 root operator4, 26 Apr 17 11:50 sd1k > brw-r- 1 root operator4, 27 Apr 17 11:50 sd1l > brw-r- 1 root operator4, 28 Apr 17 11:50 sd1m > brw-r- 1 root operator4, 29 Apr 17 11:50 sd1n > brw-r- 1 root operator4, 30 Apr 17 11:50 sd1o > brw-r- 1 root operator4, 31 Apr 17 11:50 sd1p > > Look very carefully at this column ^^ > Are they allocated in the kernel in a linear fashion? If not, you could allocate additional nodes under a spare major for the extra partitions. If so, well I'm just talking out of my arse. I'd see for myself if I could find where they're allocated. I'll have more of a deep dive later. -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: More than 16 partitions
> Medoesn't a care a flying fsck about what is "trendy". Is this the most ironic sentence ever posted on here? Dubiously censoring an expletive with a common 'Unix' utility isn't motivated by some sort of desire to feel like a part of the righteous ones? Come on.
Re: More than 16 partitions
If you didn't make any of this up, you dumbed it down to the point where there's no useful info left. You seem to operate on the assumption that merely dissing the work of companies and from ecosystems you don't like, as though it's the 'trendy' thing to do, is enough for you to get by on this forum without scrutiny. -- Patrick Harper paia...@fastmail.com On Thu, 23 Apr 2020, at 18:06, zeurk...@volny.cz wrote: > "Groot" wrote: > > I've tried and failed to create more than 16 > > partitions on OpenBSD. First of all I don't > > understand the difference between the operations > > performed by fdisk and disklabel. Is it that > > OpenBSD sees partitions differently? First we > > create an OpenBSD partition with fdisk and then > > with disklabel we can create at the most 16 more > > filesystem partitions within it. > > Traditionally, BSD has used only its own disklabel(5). Unfortunately, > mess-dos on the IBM pee-cee set a competing standard, the "Master Boot > Record", with a separate partition table (and a lot of kludging to > support more than 4 partitions). While it was (and AFAIK remains) > possible to use the whole disk the traditional way (only a BSD > disklabel, as on e.g. sparc64), it has become common practice to wrap > the BSD stuff in a mess-dos partition, with the caveat that some of the > mess-dos partition entries are duplicated in the BSD label. > > Thus, the BSD label is essentially OpenBSD's version of the structure of > things on the disk. But is an imperfect version: 16 partitions *is* the > limit for an OpenBSD label, and, of course, mess-dos partition > identifiers (which are more *ahem* fine-grained) are not used. To top it > off, partitions which rest within the mess-dos OpenBSD partition are not > necessarily represented on the mess-dos level (this would count, from > the mess-dos perspective, as overlap between partitions and thus confuse > a great many tools). > > Then GPT entered the story to make the mess complete. But me'll remain > blissfully unaware of the inner workings of that particular clusterfsck, > if you don't mind ;) > > It's no shame to be confused by this garbage. Almost all of us'd like > better, but for the above hysterical raisins, it's not so easy to make > it so. > > --zeurkous. > > -- > Friggin' Machines! > >
Re: More than 16 partitions
Amelia A Lewis wrote: > So, and I recognize that the answer might reasonably be "go read more > code and figure it out yourself," a question for Theo and others if you > have a moment: why couldn't an arch expand past sixteen? It seems, both > from the math calculating struct size (which may be mistaken, in which > case I apologize) and in the comment for MAXMAXPARTITIONS that more > *are* possible. Because there is another reason. Here are the device nodes for two sequentially-numbered disks. brw-r- 1 root operator4, 0 Apr 17 11:50 sd0a brw-r- 1 root operator4, 1 Apr 17 11:50 sd0b brw-r- 1 root operator4, 2 Apr 17 11:50 sd0c brw-r- 1 root operator4, 3 Apr 17 11:50 sd0d brw-r- 1 root operator4, 4 Apr 17 11:50 sd0e brw-r- 1 root operator4, 5 Apr 17 11:50 sd0f brw-r- 1 root operator4, 6 Apr 17 11:50 sd0g brw-r- 1 root operator4, 7 Apr 17 11:50 sd0h brw-r- 1 root operator4, 8 Apr 17 11:50 sd0i brw-r- 1 root operator4, 9 Apr 17 11:50 sd0j brw-r- 1 root operator4, 10 Apr 17 11:50 sd0k brw-r- 1 root operator4, 11 Apr 17 11:50 sd0l brw-r- 1 root operator4, 12 Apr 17 11:50 sd0m brw-r- 1 root operator4, 13 Apr 17 11:50 sd0n brw-r- 1 root operator4, 14 Apr 17 11:50 sd0o brw-r- 1 root operator4, 15 Apr 17 11:50 sd0p brw-r- 1 root operator4, 16 Apr 17 11:50 sd1a brw-r- 1 root operator4, 17 Apr 17 11:50 sd1b brw-r- 1 root operator4, 18 Apr 17 11:50 sd1c brw-r- 1 root operator4, 19 Apr 17 11:50 sd1d brw-r- 1 root operator4, 20 Apr 17 11:50 sd1e brw-r- 1 root operator4, 21 Apr 17 11:50 sd1f brw-r- 1 root operator4, 22 Apr 17 11:50 sd1g brw-r- 1 root operator4, 23 Apr 17 11:50 sd1h brw-r- 1 root operator4, 24 Apr 17 11:50 sd1i brw-r- 1 root operator4, 25 Apr 17 11:50 sd1j brw-r- 1 root operator4, 26 Apr 17 11:50 sd1k brw-r- 1 root operator4, 27 Apr 17 11:50 sd1l brw-r- 1 root operator4, 28 Apr 17 11:50 sd1m brw-r- 1 root operator4, 29 Apr 17 11:50 sd1n brw-r- 1 root operator4, 30 Apr 17 11:50 sd1o brw-r- 1 root operator4, 31 Apr 17 11:50 sd1p Look very carefully at this column ^^
Re: More than 16 partitions
I have a dread sense that I'm going to regret asking questions, but I'm
going to do it anyway, because hey, what the hell, I can always drink
bleach.
On Fri, 24 Apr 2020 19:09:53 -0600, Theo de Raadt wrote:
[snip]
>
> Reality hasn't changed. A sector is still 512 bytes, and
> disklabel has to fit in it.
I doubt that it will improve anything, but some of us (well, at least
me) got intrigued by your answers and the history (I thought that
sixteen was chosen because four bits and it was significant for that
reason, but that was clearly leaping to the same sorts of conclusions
from a different direction than disk size, which was embarrassing). So
I went and had a look at the struct definition.
Some summary for misc-readers who are not Theo or other devs; y'all
skip over me doing base-level analysis, 'kay? Otherwise you'll be rilly
annoyed with me for seeming to talk down to you, but this is for the
other folks who responded on thread without looking at disklabel.h.
/usr/src/sys/disklabel.h, the struct disklabel is the bit in question:
struct disklabel {
u_int32_t d_magic; /* the magic number */
u_int16_t d_type; /* drive type */
u_int16_t d_subtype;/* controller/d_type specific */
char d_typename[16]; /* type name, e.g. "eagle" */
char d_packname[16]; /* pack identifier */
/* disk geometry: */
u_int32_t d_secsize;/* # of bytes per sector */
u_int32_t d_nsectors; /* # of data sectors per track
*/
u_int32_t d_ntracks;/* # of tracks per cylinder */
u_int32_t d_ncylinders; /* # of data cylinders per unit
*/
u_int32_t d_secpercyl; /* # of data sectors per
cylinder */
u_int32_t d_secperunit; /* # of data sectors (low part)
*/
u_char d_uid[8]; /* Unique label identifier. */
/*
* Alternate cylinders include maintenance, replacement,
configuration
* description areas, etc.
*/
u_int32_t d_acylinders; /* # of alt. cylinders per unit
*/
/* hardware characteristics: */
u_int16_t d_bstarth;/* start of useable region
(high part) */
u_int16_t d_bendh; /* size of useable region (high
part) */
u_int32_t d_bstart; /* start of useable region */
u_int32_t d_bend; /* end of useable region */
u_int32_t d_flags; /* generic flags */
#define NDDATA 5
u_int32_t d_drivedata[NDDATA]; /* drive-type specific
information */
u_int16_t d_secperunith;/* # of data sectors (high
part) */
u_int16_t d_version;/* version # (1=48 bit
addressing) */
#define NSPARE 4
u_int32_t d_spare[NSPARE]; /* reserved for future use */
u_int32_t d_magic2; /* the magic number (again) */
u_int16_t d_checksum; /* xor of data incl. partitions
*/
/* filesystem and partition information: */
u_int16_t d_npartitions;/* number of partitions in
following */
u_int32_t d_bbsize; /* size of boot area at sn0,
bytes */
u_int32_t d_sbsize; /* max size of fs superblock,
bytes */
/* at this point, the struct as a whole occupies 160 bytes, in general
metadata
about the disklabel-as-a-whole, not any specific partition. next is
partitions: */
struct partition { /* the partition table */
u_int32_t p_size; /* number of sectors (low part)
*/
u_int32_t p_offset; /* starting sector (low part) */
u_int16_t p_offseth;/* starting sector (high part)
*/
u_int16_t p_sizeh; /* number of sectors (high
part) */
u_int8_t p_fstype; /* filesystem type, see below */
u_int8_t p_fragblock; /* encoded filesystem
frag/block */
u_int16_t p_cpg;/* UFS: FS cylinders per group
*/
} d_partitions[MAXPARTITIONS]; /* actually may be more */
};
struct partition is 16 bytes, times MAXPARTITIONS.
Note that MAXPARTITIONS isn't defined in this header; it's in the
per-arch disklabel.h (/usr/src/arch/*/include/disklabel.h). On the
other hand, at the top of the file is this:
/*
* The absolute maximum number of disk partitions allowed.
* This is the maximum value of MAXPARTITIONS for which 'struct
disklabel'
* is <= DEV_BSIZE bytes long. If MAXPARTITIONS is greater than this,
beware.
*/
#define MAXMAXPARTITIONS22
#if MAXPARTITIONS > MAXMAXPARTITIONS
#warn beware: MAXPARTITIONS bigger than MAXMAXPARTITIONS
#endif
Now, to cut to the chase, /usr/src/arch/*/include/disklabel.h all have
"#define MAXPARTITIONS 16" (whitespace varies, but the number doesn't).
So the standard/universal 16
Re: More than 16 partitions
Theo de Raadt writes: > Reality hasn't changed. A sector is still 512 bytes, and > disklabel has to fit in it. OK. Allan
Re: More than 16 partitions
Strahil Nikolov wrote: > On April 25, 2020 4:09:53 AM GMT+03:00, Theo de Raadt > wrote: > >Allan Streib wrote: > > > >> Theo de Raadt writes: > >> > >> > OpenBSD has apparently become popular amongst people who can't > >think > >> > and connect "real world constraints" and "reality" with "no > >alternative > >> > decision was possible". This is very common amongst people who > >won't > >> > lift their finger. > >> > >> I'm not the one complaining about the 16 partition limit, and I'm not > >> asking for anything to change. I've only said I think it's something > >> that is the way it is because of the design decisions made on the > >basis > >> of "reality" at the time, and which probably didn't contemplate the > >day > >> when everyone would have multi-terabyte hard drives and that people > >> might want more than 16 partitions. I stand corrected on that > >> speculation if I'm wrong. > > > >Reality hasn't changed. A sector is still 512 bytes, and > >disklabel has to fit in it. > > > >You are not LISTENING. > > Does this mean that with a sector of 4096 (modern HDDs/SSDs) and a patch - > we can have larger disklabel ? We access all disks as multiples of 512, no matter what their underlying storage layout is. We align some stuff later, but that does not change the fact "struct disklabel" is precisely 512 bytes longer. Feel free to make your own version of code that works on some machines, but not other machines. Feel free to figure out for yourself how it solves nothing.
Re: More than 16 partitions
On April 25, 2020 4:09:53 AM GMT+03:00, Theo de Raadt wrote: >Allan Streib wrote: > >> Theo de Raadt writes: >> >> > OpenBSD has apparently become popular amongst people who can't >think >> > and connect "real world constraints" and "reality" with "no >alternative >> > decision was possible". This is very common amongst people who >won't >> > lift their finger. >> >> I'm not the one complaining about the 16 partition limit, and I'm not >> asking for anything to change. I've only said I think it's something >> that is the way it is because of the design decisions made on the >basis >> of "reality" at the time, and which probably didn't contemplate the >day >> when everyone would have multi-terabyte hard drives and that people >> might want more than 16 partitions. I stand corrected on that >> speculation if I'm wrong. > >Reality hasn't changed. A sector is still 512 bytes, and >disklabel has to fit in it. > >You are not LISTENING. Does this mean that with a sector of 4096 (modern HDDs/SSDs) and a patch - we can have larger disklabel ? Best Regards, Strahil Nikolov
Re: More than 16 partitions
Allan Streib wrote: > Theo de Raadt writes: > > > OpenBSD has apparently become popular amongst people who can't think > > and connect "real world constraints" and "reality" with "no alternative > > decision was possible". This is very common amongst people who won't > > lift their finger. > > I'm not the one complaining about the 16 partition limit, and I'm not > asking for anything to change. I've only said I think it's something > that is the way it is because of the design decisions made on the basis > of "reality" at the time, and which probably didn't contemplate the day > when everyone would have multi-terabyte hard drives and that people > might want more than 16 partitions. I stand corrected on that > speculation if I'm wrong. Reality hasn't changed. A sector is still 512 bytes, and disklabel has to fit in it. You are not LISTENING.
Re: More than 16 partitions
Theo de Raadt writes: > OpenBSD has apparently become popular amongst people who can't think > and connect "real world constraints" and "reality" with "no alternative > decision was possible". This is very common amongst people who won't > lift their finger. I'm not the one complaining about the 16 partition limit, and I'm not asking for anything to change. I've only said I think it's something that is the way it is because of the design decisions made on the basis of "reality" at the time, and which probably didn't contemplate the day when everyone would have multi-terabyte hard drives and that people might want more than 16 partitions. I stand corrected on that speculation if I'm wrong. Allan
Re: More than 16 partitions
Ingo Schwarze wrote: The limitation to 16 partitions definitely feels painful to me. There is softraid(4). The only discipline that supports a single chunk is crypto. Make a couple of OpenBSD RAID partitions, set them up as crypto, partition those new crypto pseudo-devices, up to 16 partitions each, mkfs, mount, profit. From what I understand, crypto is not that big a performance hit if you have AES on your AMD64 intruction set. I just tried it on a small 16GB usb flash drive. The only issue was getting a clean reboot (rc.local to configure the pseudo-devices succeeds but mount happens too early). John
Re: More than 16 partitions
A little bit of fun, slightly related to some of the discussion: [1] is something that comes into my mind each time i read some of the emails [2] is coming next [1] https://www.youtube.com/watch?v=nlt5Wa13fFU [2] https://www.youtube.com/watch?v=zIV4poUZAQo
Re: More than 16 partitions
Allan Streib wrote: > Theo de Raadt writes: > > > Allan Streib wrote: > > > >> Seems like one of those numbers that was chosen long ago, when disks > >> had orders of magnitude less storage capacity they have now, and 16 > >> partitions really would have been more than enough. > > > > the word "chosen" makes it seem like such an arbitrary decision. > > No, didn't mean to imply arbitrary or ill-considered, more that > someone(s) decided that to be an adequate number, considering various > requirements and constraints. At the time, that would probably not have > included the common availability of multi-terabyte drives. Obviously I > wasn't there. Incorrect. And wow, you demonstrate an amazing inability to read. All the offsets and sizes have to fit in a 512 byte sector. It wasn't chosen. THERE WAS NO OTHER WAY. OpenBSD has apparently become popular amongst people who can't think and connect "real world constraints" and "reality" with "no alternative decision was possible". This is very common amongst people who won't lift their finger.
Re: More than 16 partitions
Theo de Raadt writes: > Allan Streib wrote: > >> Seems like one of those numbers that was chosen long ago, when disks >> had orders of magnitude less storage capacity they have now, and 16 >> partitions really would have been more than enough. > > the word "chosen" makes it seem like such an arbitrary decision. No, didn't mean to imply arbitrary or ill-considered, more that someone(s) decided that to be an adequate number, considering various requirements and constraints. At the time, that would probably not have included the common availability of multi-terabyte drives. Obviously I wasn't there. Allan
Re: More than 16 partitions
Allan Streib wrote:
> Seems like one of those numbers that was chosen long ago, when disks
> had orders of magnitude less storage capacity they have now, and 16
> partitions really would have been more than enough.
the word "chosen" makes it seem like such an arbitrary decision.
As currently written, the partition table must fit in a single sector.
Read disklabel.h and figure out how this part works:
struct partition { /* the partition table */
u_int32_t p_size; /* number of sectors (low part) */
u_int32_t p_offset; /* starting sector (low part) */
u_int16_t p_offseth;/* starting sector (high part) */
u_int16_t p_sizeh; /* number of sectors (high part) */
u_int8_t p_fstype; /* filesystem type, see below */
u_int8_t p_fragblock; /* encoded filesystem frag/block */
u_int16_t p_cpg;/* UFS: FS cylinders per group */
} d_partitions[MAXPARTITIONS]; /* actually may be more */
...
#define DL_GETDSIZE(d) (((u_int64_t)(d)->d_secperunith << 32) + \
(d)->d_secperunit)
#define DL_SETDSIZE(d, n) do { \
u_int64_t x = (n); \
(d)->d_secperunith = x >> 32; \
(d)->d_secperunit = x; \
} while (0)
#define DL_GETBSTART(d) (((u_int64_t)(d)->d_bstarth << 32) + \
(d)->d_bstart)
#define DL_SETBSTART(d, n) do { \
u_int64_t x = (n); \
(d)->d_bstarth = x >> 32; \
(d)->d_bstart = x; \
} while (0)
etc etc etc
Long time ago, it was chosen that cars should have 4 wheels.
Re: More than 16 partitions
Ingo Schwarze writes: > The limitation to 16 partitions definitely feels painful to me. Well, one pragmatic solution is to add another disk -- 16 more partitions. Not always possible, granted. Seems like one of those numbers that was chosen long ago, when disks had orders of magnitude less storage capacity they have now, and 16 partitions really would have been more than enough. Allan
Re: More than 16 partitions
Lars, Your email didn't contain a diff. Is there a reason for that? I'm wondering whether it is because it is too difficult for you, or maybe it is too difficult for everyone, or maybe you are simply talking out of your ass by trying to assign work to other people because that is your nature? > HAMMER2 could be ported. There is much collaboration between OpenBSD > and DragonflyBSD already (drivers for example). > https://www.dragonflybsd.org/docs/handbook/environmentquickstart/#index3h2 > > On Thu, 2020-04-23 at 16:48 -0400, Eric Furman wrote: > > ZFS cannot be ported to OBSD. It has an unacceptable license. > > If something like it were to be used on OBSD it would have to be > > written from scratch with a BSD license and it has already been > > discussed at length on this list how hard that is. > > Besides it is not really necessary. ZFS is overly complex and not > > needed in most cases. > -- > Lars Schotte > Mudroňova 13 > 92101 Piešťany >
Re: More than 16 partitions
HAMMER2 could be ported. There is much collaboration between OpenBSD and DragonflyBSD already (drivers for example). https://www.dragonflybsd.org/docs/handbook/environmentquickstart/#index3h2 On Thu, 2020-04-23 at 16:48 -0400, Eric Furman wrote: > ZFS cannot be ported to OBSD. It has an unacceptable license. > If something like it were to be used on OBSD it would have to be > written from scratch with a BSD license and it has already been > discussed at length on this list how hard that is. > Besides it is not really necessary. ZFS is overly complex and not > needed in most cases. -- Lars Schotte Mudroňova 13 92101 Piešťany
Re: More than 16 partitions
Hi Strahil, Strahil Nikolov wrote on Thu, Apr 23, 2020 at 11:16:41PM +0300: > And who the hell needs more than 16 partitions ? Me, and i'm quite sure many do. It's certainly not a good idea to combine any partitions that are separate in a default install because there are good reasons for all the separations. Then, on a development machine, i want separate partitions for src, xenocara, ports and the related obj partitions. Then i need a noperm partition for building releases. And because i sometimes work on free software projects outside OpenBSD, i want a partition for source code control checkouts of other projects. I certainly don't want to to mix /co/ that into /home/ or /usr/src/. At this point, here is the bare minimum i typically have: 01 a / 02 b swap 03 c whole disk 04 d /tmp nodev nosuid 05 e /var nodev nosuid 06 f /usr nodev 07 g /usr/local nodev wxallowed 08 h /usr/src nodev nosuid 09 i /usr/obj nodev nosuid 10 j /usr/xenocaranodev nosuid 11 k /usr/xobjnodev nosuid 12 l /usr/ports nodev nosuid 13 m /usr/ports/pobj nodev nosuid wxallowed 14 n /co nodev nosuid 15 o /co/destdir nodev noexec noperm 16 p /homenodev nosuid So, i'm out of partitions before i even start doing anything even mildly special. I don't even have a single spare partition, even though having that would be quite useful for better keeping track of unused space on the disk that i might keep around for maybe using it later. The limitation to 16 partitions definitely feels painful to me. > Why not we just port ZFS from FreeBSD, or LVM from Linux For starters, neither are free software. Both are encumbered with very restrictive licenses that prevent using them last time i looked (CDDL and GPL). Besides, OpenBSD values code that is small, simple, and easy to audit, so i'm not sure whether these would qualify even if they were free. So trying to port them would be a waste of time. Trying to port HAMMER from DragonFly might be worthwhile, but a huge and difficult project, and i'm not sure it is related to the limitation of the number of partitions. Yours, Ingo
Re: More than 16 partitions
On 2020-04-23, Ian Darwin wrote: > So: I was able to newfs, mount, and use an OpenBSD partition which > disklabel called 'a' and which had no trace of an fdisk partition around it. > > As Allan pointed out, this is not for booting from - none of those > fdisk partitions looks very healthy. biosboot(8) has an MBR boot signature. If the BIOS doesn't check for a valid MBR partition table--some do, some don't--then it should be able to directly run biosboot(8) from sector 0. installboot(8) tries to prevent such a configuration, but it could be tweaked, or you could try to tweak the disklabel and set the type to floppy, because floppies don't have MBR partitions. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: More than 16 partitions
On 2020-04-24 04:45, zeurk...@volny.cz wrote: > Your point is well-taken (though this is just the way mespeaks); yet, > Theo is a native speaker No-one is a native speaker of this made up crap, mecraps
Re: More than 16 partitions
On Thu, Apr 23, 2020 at 10:29:01PM +0200, Francois Pussault wrote: > I agree ; Using more than 10 partitions is rare but in case of NFS or other > network shares of course. > 16 is really enough in my point of view. > I've got to disgree with this one. I'm doing porting work. I yank out all of the directories except /usr/ports itself, using mk.conf. I then also make another partition /usr/ports/mystuff umount /usr/ports/mystuff umount /usr/ports newfs /usr/ports, etc. remount /usr/ports, mkdir /usr/ports/mystuff, remount /usr/ports/mystuff tar xzvf ports.tar.gz into /usr/ports and I can continue on working, without having lost any work I'm still examining. Working with retail equipment at home for a normal desktop. 16 OK Power often fails or hardware fails. Working on a server. Power almost never fails, nor the hardware. At home I run built-in HD, USB flash and USB HD. 16 is no problem with three HD's. I can ro lots of stuff and I need to. I'm not doing any porting at home, only on server hardware. Too tired of reliability issues at home. That's just what I(me)thinks. |-} There be-is-are some very good, cheap, rugged and waterproof USB HD's out there. Very portable(s). Bye, Chris
Re: More than 16 partitions
On 2020-04-23 11:45, zeurk...@volny.cz wrote: "Jan Betlach" wrote: For a non-native English speaker like myself, it is very difficult to read your mestuff... Your point is well-taken (though this is just the way mespeaks); yet, Theo is a native speaker, and he seems to have completely missed the content of merecent responses. Weird, isn't it? Anyway, as this would appear to be quite OT, me'd suggest we continue this (if at all) in private mail... Jan Take care, --zeurkous. Say Hi to Boss Nass for me next time you're in Otoh Gunga. Jordan
Re: More than 16 partitions
On Thu, Apr 23, 2020 at 04:42:53PM -0400, Allan Streib wrote: > > So, can I setup openBSD labels on x86_64 without legacy/GPT partition > > first ? > > IIRC yes you can, as long as you don't need to boot from that disk. Easily confirmed (a few false starts deleted from this transcript): $ uname -a OpenBSD foo.darwinsys.com 6.7 GENERIC.MP#145 amd64 # Here I plugged in a cheap USB device $ dmesg | tail -4 umass0: using SCSI over Bulk-Only scsibus4 at umass0: 2 targets, initiator 0 sd2 at scsibus4 targ 1 lun 0: removable serial.18a5023805270130 sd2: 3750MB, 512 bytes/sector, 768 sectors # Trash any existing fdisk and disklabel info # dd if=/dev/random of=/dev/rsd2c bs=512 count=100 100+0 records in 100+0 records out 51200 bytes transferred in 0.068 secs (742845 bytes/sec) # disklabel sd2 # /dev/rsd2c: type: SCSI disk: SCSI disk label: Store n Go Drive duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 478 total sectors: 768 boundstart: 0 boundend: 768 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c: 7680 unused i: 7679944 56 MSDOS # fdisk sd2 # confirm there is no fdisk table, just random rubbish Disk: sd2 geometry: 478/255/63 [768 Sectors] Offset: 0 Signature: 0x111 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 82 77157 27 55 - 172421 98 24 [ 1239528960: 1530420603 ] Linux swap 1: 64 10096 3 23 - 176047 141 26 [ 162192451: 2666011513 ] NetWare 2.xx 2: 6E 252409 74 42 - 209458 117 56 [ 4054955288: 3604962205 ] 3: A9 19978 12 42 - 22375 228 62 [ 320947367:38521434 ] NetBSD # disklabel -E sd2 Label editor (enter '?' for help at any prompt) sd2> p OpenBSD area: 0-768; size: 768; free: 768 #size offset fstype [fsize bsize cpg] c: 7680 unused sd2> a partition: [a] offset: [0] 64 size: [7679936] 100M FS type: [4.2BSD] sd2*> w sd2> q No label changes. # newfs /dev/rsd2a /dev/rsd2a: 101.9MB in 208768 sectors of 512 bytes 4 cylinder groups of 25.48MB, 1631 blocks, 3328 inodes each super-block backups (for fsck -b #) at: 32, 52224, 104416, 156608, # mount /dev/sd2a /mnt $ ls /mnt $ date | doas dd of=/mnt/date.txt 0+1 records in 0+1 records out 29 bytes transferred in 0.000 secs (322584 bytes/sec) $ ls /mnt date.txt $ cat /mnt/date.txt Thu Apr 23 18:55:35 EDT 2020 # fdisk sd2 # still no fdisk table Disk: sd2 geometry: 478/255/63 [768 Sectors] Offset: 0 Signature: 0x111 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 82 77157 27 55 - 172421 98 24 [ 1239528960: 1530420603 ] Linux swap 1: 64 10096 3 23 - 176047 141 26 [ 162192451: 2666011513 ] NetWare 2.xx 2: 6E 252409 74 42 - 209458 117 56 [ 4054955288: 3604962205 ] 3: A9 19978 12 42 - 22375 228 62 [ 320947367:38521434 ] NetBSD # So: I was able to newfs, mount, and use an OpenBSD partition which disklabel called 'a' and which had no trace of an fdisk partition around it. As Allan pointed out, this is not for booting from - none of those fdisk partitions looks very healthy.
Re: More than 16 partitions
> > From: Strahil Nikolov > Sent: Thu Apr 23 22:16:41 CEST 2020 > To: , Theo de Raadt , > > Cc: Martin Schröder > Subject: Re: More than 16 partitions > > > On April 23, 2020 10:46:44 PM GMT+03:00, Theo de Raadt > wrote: > >You need to stop making this mailing list just about you. > > > >STFU. > > > > > > wrote: > > > >> "Martin Schröder" wrote: > >> > Am Do., 23. Apr. 2020 um 21:31 Uhr schrieb : > >> >> No problem. Would it be too crude a suggestion that we go back to > >the > >> >> content now...? > >> > > >> > You didn't provide any patch. > >> > >> That is entirely correct. > >> > >> --zeurkous. > >> > >> -- > >> Friggin' Machines! > >> > > Some of these e-mails were useful others not... > > So, can I setup openBSD labels on x86_64 without legacy/GPT partition first ? > And who the hell needs more than 16 partitions ? Why not we just port ZFS > from FreeBSD, or LVM from Linux and get over it ? hello, I agree ; Using more than 10 partitions is rare but in case of NFS or other network shares of course. 16 is really enough in my point of view. > > P.S.: The last one was not a real question, but I would like to hear if > anyone has attempted to port any of these 2 . > > Best Regards, > Strahil Nikolov > Cordialement Francois Pussault 10 chemin de négo saoumos apt 202 - bat 2 31300 Toulouse +33 6 17 230 820 fpussa...@contactoffice.fr
Re: More than 16 partitions
On Thu, Apr 23, 2020 at 08:14:25PM +0200, Jan Betlach wrote: > For a non-native English speaker like myself, it is very difficult to read > your mestuff… One may practice by reading Gollum/Smeagol-passages..
Re: More than 16 partitions
For a non-native English speaker like myself, it is very difficult to read your mestuff… Jan On 23 Apr 2020, at 19:47, zeurk...@volny.cz wrote: theo wrote: That is a rewriting of history. It's history the way meknows it. Mecertainly predates some of it. The disklabel format predates the PC. Indeed. Mewasn't sure where and when exactly it appeared, so meleft that bit out. But medid know it was older, and metried to communicate that fact (obviously mefailed -- meapologizes). It came from the the ancient attempt to handle things in CSRG's 4.3reno/4.4 work on the hp300. It was probably a rewrite of the native HPUX disk format. Hmm, hp300, eh? This was then put on all the other architectures, as a unified view of the disk. It was modified and extended on as as-needed basis. Rewriting the history like this is pathetic inaccurate and narrowminded. Your history is absolutely false and you've made up a bunch of balony. So, what did memake up? Did mepresent a timeline? An exact order of events? Did mepresent a scientific study? Or didmejust try to give an overview of things in terms that Groot (and many others, mesuspects) may just understand? It is not true, and even a elementary review of the history of disklabel.h back into the early NetBSD tree will make it clear what's going on. Like mesaid, it's the history the way meknows it. Me's not a bloody authority on the history of either BSD or the IBM pee-cee, *at all*. Perhaps meshould've made that clearer. OH, and I did most of the early work post-CSRG, because we needed to "emulate" this on SunOS, and I ported Torek's sparc code into NetBSD. Mehas _no doubt at all_ that you know BSD (including its history) better than me (that is, of course, an understatement). I urge you to stop posting such balony. Then it's me turn to urge you to not read me overview as an historical account of any exactness. After all, the goal, for me, was trying to help Groot understand the relationships he sought clarification for. Perhaps meindeed should've included a disclaimer. Then again, mehas no offical role here (nor does mewant one), and in no way are me words to be taken for the one and universal truth. Can we please just assume that Groot is mature enough to be able to form his own view based on our individual contributions? Me'd like that. --zeurkous. -- Friggin' Machines!
Re: More than 16 partitions
On Thu, Apr 23, 2020, at 4:16 PM, Strahil Nikolov wrote: > So, can I setup openBSD labels on x86_64 without legacy/GPT partition > first ? > And who the hell needs more than 16 partitions ? Why not we just port > ZFS from FreeBSD, or LVM from Linux and get over it ? > > P.S.: The last one was not a real question, but I would like to hear > if anyone has attempted to port any of these 2 . ZFS cannot be ported to OBSD. It has an unacceptable license. If something like it were to be used on OBSD it would have to be written from scratch with a BSD license and it has already been discussed at length on this list how hard that is. Besides it is not really necessary. ZFS is overly complex and not needed in most cases.
Re: More than 16 partitions
> So, can I setup openBSD labels on x86_64 without legacy/GPT partition first ? IIRC yes you can, as long as you don't need to boot from that disk. Allan
Re: More than 16 partitions
On April 23, 2020 10:46:44 PM GMT+03:00, Theo de Raadt wrote: >You need to stop making this mailing list just about you. > >STFU. > > > wrote: > >> "Martin Schröder" wrote: >> > Am Do., 23. Apr. 2020 um 21:31 Uhr schrieb : >> >> No problem. Would it be too crude a suggestion that we go back to >the >> >> content now...? >> > >> > You didn't provide any patch. >> >> That is entirely correct. >> >> --zeurkous. >> >> -- >> Friggin' Machines! >> Some of these e-mails were useful others not... So, can I setup openBSD labels on x86_64 without legacy/GPT partition first ? And who the hell needs more than 16 partitions ? Why not we just port ZFS from FreeBSD, or LVM from Linux and get over it ? P.S.: The last one was not a real question, but I would like to hear if anyone has attempted to port any of these 2 . Best Regards, Strahil Nikolov
Re: More than 16 partitions
You need to stop making this mailing list just about you. STFU. wrote: > "Martin Schröder" wrote: > > Am Do., 23. Apr. 2020 um 21:31 Uhr schrieb : > >> No problem. Would it be too crude a suggestion that we go back to the > >> content now...? > > > > You didn't provide any patch. > > That is entirely correct. > > --zeurkous. > > -- > Friggin' Machines! >
RE: More than 16 partitions
"Martin Schröder" wrote: > Am Do., 23. Apr. 2020 um 21:31 Uhr schrieb : >> No problem. Would it be too crude a suggestion that we go back to the >> content now...? > > You didn't provide any patch. That is entirely correct. --zeurkous. -- Friggin' Machines!
Re: More than 16 partitions
Am Do., 23. Apr. 2020 um 21:31 Uhr schrieb : > No problem. Would it be too crude a suggestion that we go back to the > content now...? You didn't provide any patch.
RE: More than 16 partitions
"Christian Groessler" wrote: > On 4/23/20 7:57 PM, zeurk...@volny.cz wrote: > >> theo wrote: >>> You made it all up. >> That's an easy accusation, with an easy response: No, medid not make any >> of it up > > > Could you refrain from using your idiotic "me.."-words? Fine, me'll try and keep the idiotic ones out. > Thanks No problem. Would it be too crude a suggestion that we go back to the content now...? --zeurkous. -- Friggin' Machines!
Re: More than 16 partitions
On 4/23/20 7:57 PM, zeurk...@volny.cz wrote: theo wrote: You made it all up. That's an easy accusation, with an easy response: No, medid not make any of it up Could you refrain from using your idiotic "me.."-words? Thanks
RE: More than 16 partitions
"Jan Betlach" wrote: > For a non-native English speaker like myself, it is very difficult to > read your mestuff... Your point is well-taken (though this is just the way mespeaks); yet, Theo is a native speaker, and he seems to have completely missed the content of merecent responses. Weird, isn't it? Anyway, as this would appear to be quite OT, me'd suggest we continue this (if at all) in private mail... > Jan Take care, --zeurkous. -- Friggin' Machines!
RE: More than 16 partitions
theo wrote: > You made it all up. That's an easy accusation, with an easy response: No, medid not make any of it up. --zeurkous. -- Friggin' Machines!
Re: More than 16 partitions
You made it all up. wrote: > theo wrote: > > That is a rewriting of history. > > It's history the way meknows it. Mecertainly predates some of it. > > > The disklabel format predates the PC. > > Indeed. Mewasn't sure where and when exactly it appeared, so meleft that > bit out. But medid know it was older, and metried to communicate that > fact (obviously mefailed -- meapologizes). > > > It came from the the ancient attempt to handle things in CSRG's > > 4.3reno/4.4 work on the hp300. It was probably a rewrite of the > > native HPUX disk format. > > Hmm, hp300, eh? > > > This was then put on all the other architectures, as a unified > > view of the disk. It was modified and extended on as as-needed > > basis. > > > > Rewriting the history like this is pathetic inaccurate and > > narrowminded. Your history is absolutely false and you've made > > up a bunch of balony. > > So, what did memake up? Did mepresent a timeline? An exact order of > events? Did mepresent a scientific study? Or didmejust try to give an > overview of things in terms that Groot (and many others, mesuspects) may > just understand? > > > It is not true, and even a elementary > > review of the history of disklabel.h back into the early NetBSD > > tree will make it clear what's going on. > > Like mesaid, it's the history the way meknows it. Me's not a bloody > authority on the history of either BSD or the IBM pee-cee, *at all*. > > Perhaps meshould've made that clearer. > > > OH, and I did most of the early work post-CSRG, because we needed > > to "emulate" this on SunOS, and I ported Torek's sparc code into > > NetBSD. > > Mehas _no doubt at all_ that you know BSD (including its history) better > than me (that is, of course, an understatement). > > > I urge you to stop posting such balony. > > Then it's me turn to urge you to not read me overview as an historical > account of any exactness. > > After all, the goal, for me, was trying to help Groot understand the > relationships he sought clarification for. > > Perhaps meindeed should've included a disclaimer. Then again, mehas no > offical role here (nor does mewant one), and in no way are me words to > be taken for the one and universal truth. > > Can we please just assume that Groot is mature enough to be able to form > his own view based on our individual contributions? > > Me'd like that. > > --zeurkous. > > -- > Friggin' Machines!
RE: More than 16 partitions
theo wrote: > That is a rewriting of history. It's history the way meknows it. Mecertainly predates some of it. > The disklabel format predates the PC. Indeed. Mewasn't sure where and when exactly it appeared, so meleft that bit out. But medid know it was older, and metried to communicate that fact (obviously mefailed -- meapologizes). > It came from the the ancient attempt to handle things in CSRG's > 4.3reno/4.4 work on the hp300. It was probably a rewrite of the > native HPUX disk format. Hmm, hp300, eh? > This was then put on all the other architectures, as a unified > view of the disk. It was modified and extended on as as-needed > basis. > > Rewriting the history like this is pathetic inaccurate and > narrowminded. Your history is absolutely false and you've made > up a bunch of balony. So, what did memake up? Did mepresent a timeline? An exact order of events? Did mepresent a scientific study? Or didmejust try to give an overview of things in terms that Groot (and many others, mesuspects) may just understand? > It is not true, and even a elementary > review of the history of disklabel.h back into the early NetBSD > tree will make it clear what's going on. Like mesaid, it's the history the way meknows it. Me's not a bloody authority on the history of either BSD or the IBM pee-cee, *at all*. Perhaps meshould've made that clearer. > OH, and I did most of the early work post-CSRG, because we needed > to "emulate" this on SunOS, and I ported Torek's sparc code into > NetBSD. Mehas _no doubt at all_ that you know BSD (including its history) better than me (that is, of course, an understatement). > I urge you to stop posting such balony. Then it's me turn to urge you to not read me overview as an historical account of any exactness. After all, the goal, for me, was trying to help Groot understand the relationships he sought clarification for. Perhaps meindeed should've included a disclaimer. Then again, mehas no offical role here (nor does mewant one), and in no way are me words to be taken for the one and universal truth. Can we please just assume that Groot is mature enough to be able to form his own view based on our individual contributions? Me'd like that. --zeurkous. -- Friggin' Machines!
Re: More than 16 partitions
That is a rewriting of history. The disklabel format predates the PC. It came from the the ancient attempt to handle things in CSRG's 4.3reno/4.4 work on the hp300. It was probably a rewrite of the native HPUX disk format. This was then put on all the other architectures, as a unified view of the disk. It was modified and extended on as as-needed basis. Rewriting the history like this is pathetic inaccurate and narrowminded. Your history is absolutely false and you've made up a bunch of balony. It is not true, and even a elementary review of the history of disklabel.h back into the early NetBSD tree will make it clear what's going on. OH, and I did most of the early work post-CSRG, because we needed to "emulate" this on SunOS, and I ported Torek's sparc code into NetBSD. I urge you to stop posting such balony. wrote: > "Groot" wrote: > > I've tried and failed to create more than 16 > > partitions on OpenBSD. First of all I don't > > understand the difference between the operations > > performed by fdisk and disklabel. Is it that > > OpenBSD sees partitions differently? First we > > create an OpenBSD partition with fdisk and then > > with disklabel we can create at the most 16 more > > filesystem partitions within it. > > Traditionally, BSD has used only its own disklabel(5). Unfortunately, > mess-dos on the IBM pee-cee set a competing standard, the "Master Boot > Record", with a separate partition table (and a lot of kludging to > support more than 4 partitions). While it was (and AFAIK remains) > possible to use the whole disk the traditional way (only a BSD > disklabel, as on e.g. sparc64), it has become common practice to wrap > the BSD stuff in a mess-dos partition, with the caveat that some of the > mess-dos partition entries are duplicated in the BSD label. > > Thus, the BSD label is essentially OpenBSD's version of the structure of > things on the disk. But is an imperfect version: 16 partitions *is* the > limit for an OpenBSD label, and, of course, mess-dos partition > identifiers (which are more *ahem* fine-grained) are not used. To top it > off, partitions which rest within the mess-dos OpenBSD partition are not > necessarily represented on the mess-dos level (this would count, from > the mess-dos perspective, as overlap between partitions and thus confuse > a great many tools). > > Then GPT entered the story to make the mess complete. But me'll remain > blissfully unaware of the inner workings of that particular clusterfsck, > if you don't mind ;) > > It's no shame to be confused by this garbage. Almost all of us'd like > better, but for the above hysterical raisins, it's not so easy to make > it so. > > --zeurkous. > > -- > Friggin' Machines! >
RE: More than 16 partitions
"Groot" wrote: > I've tried and failed to create more than 16 > partitions on OpenBSD. First of all I don't > understand the difference between the operations > performed by fdisk and disklabel. Is it that > OpenBSD sees partitions differently? First we > create an OpenBSD partition with fdisk and then > with disklabel we can create at the most 16 more > filesystem partitions within it. Traditionally, BSD has used only its own disklabel(5). Unfortunately, mess-dos on the IBM pee-cee set a competing standard, the "Master Boot Record", with a separate partition table (and a lot of kludging to support more than 4 partitions). While it was (and AFAIK remains) possible to use the whole disk the traditional way (only a BSD disklabel, as on e.g. sparc64), it has become common practice to wrap the BSD stuff in a mess-dos partition, with the caveat that some of the mess-dos partition entries are duplicated in the BSD label. Thus, the BSD label is essentially OpenBSD's version of the structure of things on the disk. But is an imperfect version: 16 partitions *is* the limit for an OpenBSD label, and, of course, mess-dos partition identifiers (which are more *ahem* fine-grained) are not used. To top it off, partitions which rest within the mess-dos OpenBSD partition are not necessarily represented on the mess-dos level (this would count, from the mess-dos perspective, as overlap between partitions and thus confuse a great many tools). Then GPT entered the story to make the mess complete. But me'll remain blissfully unaware of the inner workings of that particular clusterfsck, if you don't mind ;) It's no shame to be confused by this garbage. Almost all of us'd like better, but for the above hysterical raisins, it's not so easy to make it so. --zeurkous. -- Friggin' Machines!
RE: More than 16 partitions
Haai, theo wrote: > Groot wrote: > >> I've tried and failed to create more than 16 >> partitions on OpenBSD. First of all I don't >> understand the difference between the operations >> performed by fdisk and disklabel. Is it that >> OpenBSD sees partitions differently? First we >> create an OpenBSD partition with fdisk and then >> with disklabel we can create at the most 16 more >> filesystem partitions within it. >> >> But if I want more than 16 filesystem partitions >> on a single disk naturally I try to create more >> fdisk partitions and then within it lay more fs- >> partitions. When I try that OpenBSD doesn't >> recognize those partitions and I can't even run >> 'newfs' on those partitions. Is there a way for >> OpenBSD to deal with more than 16 partitions? >> > > Sorry, there is no way. > > You can create a vnd, on a file, and then that vnd can contain > partitions. But it might suck. Me's configured a pair of consecutive softraid(4) partitions in concat mode. Sees relatively light use, but performance has been adequate. Previously, meused crypto w/ a passphrase of '0' (automagically read from a file at boot), but that was just needlessly complicated. Fixing vnd(4) to work on devices, or just adding a 'concat-of-1-volume' (perhaps call it 'L'ayer) "level" to softraid, is what me'd recommend. But that doesn't seem to help Groot (right now). Hope the above helps, --zeurkous. -- Friggin' Machines!
Re: More than 16 partitions
Groot wrote: > I've tried and failed to create more than 16 > partitions on OpenBSD. First of all I don't > understand the difference between the operations > performed by fdisk and disklabel. Is it that > OpenBSD sees partitions differently? First we > create an OpenBSD partition with fdisk and then > with disklabel we can create at the most 16 more > filesystem partitions within it. > > But if I want more than 16 filesystem partitions > on a single disk naturally I try to create more > fdisk partitions and then within it lay more fs- > partitions. When I try that OpenBSD doesn't > recognize those partitions and I can't even run > 'newfs' on those partitions. Is there a way for > OpenBSD to deal with more than 16 partitions? > Sorry, there is no way. You can create a vnd, on a file, and then that vnd can contain partitions. But it might suck.
