Re: [Freedos-devel] Free FDISK interim builds
> Am 10.03.2023 um 19:53 schrieb Bernd Böckmann : > > /SMBR command to write the MBR to disk to file of course… ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi, I hope I have eliminated the most critical bugs and I am now in a cleanup phase. I noticed that the /SMBR command to write the MBR to disk does not do what its name suggests. It only writes the 440 code bytes to the file and fills the rest of the 512 bytes with zero, leaving FDISK with no method to make a backup of the partition layout. I reworked the commands, so that the users don’t get confused: MBR (Master Boot Record) management: /CLEARMBR [drive#] Fills MBR with zero: deletes all part. and code /LOADMBR [drive#] Loads part. table and code from "boot.mbr" into MBR /SAVEMBR [drive#] Saves partition table and code into file "boot.mbr" MBR code modifications leaving partitions intact: /IPL [drive#] Writes the standard boot code into MBR ...same as /MBR and /CMBR for compatibility /CLEARIPL [drive#] Zeros 440 code bytes of MBR /LOADIPL [drive#] Writes 440 code bytes from "boot.mbr" into MBR /SMARTIPL [drive#] Writes DriveSmart IPL into MBR The /CLEARIPL is only there because that functionality existed before. I am not sure if it does make sense at all if 55 AA marks a valid MBR. I have the tendency to remove it unless someone intervenes, because there is also /CLEARMBR to clean sector 0 properly. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
On Sun, 5 Mar 2023 20:41:58 +0100 Bernd Boeckmann via Freedos-devel wrote: > FDISK now aligns all partitions to 4K if the configuration option > ALIGN_4K=ON, which is the default. > > For backwards compatibility, ALIGN_4K=OFF restores the old behavior > (cylinder alignment). Then it also points out if an existing Extended > Partition is not aligned, but hopefully does not produce broken > layouts anymore. Thanks for adding this functionality! -- WWW: https://metalpunks.info GPG: C90CAB7122AC1231 pgplyAap0WwEz.pgp Description: OpenPGP digital signature ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi, I am so far through with the implementation of functionality I want to have in version 1.4. I still have to test it properly and hopefully have a version that can be included in the next FreeDOS monthly. The current build, compiled with Open Watcom 1.9 for 8086, can be obtained from https://nextcloud.iww.rwth-aachen.de/index.php/s/egSe4Jyj9zx72ag FDISK now aligns all partitions to 4K if the configuration option ALIGN_4K=ON, which is the default. For backwards compatibility, ALIGN_4K=OFF restores the old behavior (cylinder alignment). Then it also points out if an existing Extended Partition is not aligned, but hopefully does not produce broken layouts anymore. Furthermore, the LBA_MARKER option is new and ON by default. This replaces the overflowed CHS values in the partition tables with 1023/254/63. LBA_MARKER=OFF produces "correct" cylinder overflow. FDISK should handle disks of up to 2TB correctly. Disks larger than that are truncated to 2TB instead of some overflowed value. Since the size calculation still runs on cylinder basis space is wasted here and there. If one would like to turn this off one would have to change the determination of the free memory areas to sector accuracy. That would be some more work. I am not sure it is worth the effort. EasyMBR is still in but disabled. Jerome has a ticket on that. https://gitlab.com/FreeDOS/base/fdisk/-/issues/3 Obvious is the missing LBA support. Other than that, I didn't notice anything major when I skimmed it. Does anyone have more details why it exactly was deactivated in the past? If we don't fix it, I wouldn't link it into the binary anymore. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
>>> The reason why partition boundaries are aligned on cylinder boundaries >>> is that a lot of other OSes also rely on that. >> any example of this? I don't any (not completely braindead) operating >> system would rely on that; it's just the way that FDISK and friends >> place partitions on the disk. > Well, Linux might do this, I am pretty sure older DOS versions do, OS/2 > and Windows 9x is likely to do this as well. what "this"? placing partitions on a cylinder boundary? well, FDISK did this as well until now. > This was a very common problem what kind of "problem"? > and I know that I was talking with Brian about this when he was > still the maintainer of FDISK, but my current emails for this (and other > FreeDOS related ones) are only going back until 2013 and this was > discussed before that. Sorry, Brian (in the ~2004 timeframe) was completely, utter clueless about just everything. that's why FDISK is such a mess. citing him as kind of expert doesn't support your case. > A quick Google search before heading out of the office found for example > this: > https://www.linuxquestions.org/questions/ubuntu-63/how-to-fix-%27partition-not-end-on-cylinder-boundary%27-768635/ "Not a problem - ignore it." > or this > https://www.veritas.com/support/en_US/article.100025188 ?? again: what kind of problem? not ending on a cylinder boundary is NOT a problem. however it shouldn't be a alignment problem if it would always do. Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
On 3/1/2023 9:13 AM, tom ehlert wrote: The reason why partition boundaries are aligned on cylinder boundaries is that a lot of other OSes also rely on that. any example of this? I don't any (not completely braindead) operating system would rely on that; it's just the way that FDISK and friends place partitions on the disk. Well, Linux might do this, I am pretty sure older DOS versions do, OS/2 and Windows 9x is likely to do this as well. This was a very common problem and I know that I was talking with Brian about this when he was still the maintainer of FDISK, but my current emails for this (and other FreeDOS related ones) are only going back until 2013 and this was discussed before that. A quick Google search before heading out of the office found for example this: https://www.linuxquestions.org/questions/ubuntu-63/how-to-fix-%27partition-not-end-on-cylinder-boundary%27-768635/ or this https://www.veritas.com/support/en_US/article.100025188 Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hallo Herr Ralf Quint, am Mittwoch, 1. März 2023 um 18:08 schrieben Sie: > On 3/1/2023 8:22 AM, Bernd Boeckmann via Freedos-devel wrote: >> Hello, >> >> I am now reaching a state where I think that FDISK not any longer breaks the >> partition layouts created by itself. >> >> However, there is at least still one MAJOR flaw when dealing with partition >> layouts created by other partition managers: >> >> If there exists an extended partition with a start address not aligned to >> cylinder boundaries, the position and size determination for logical drives >> is completely messed up. >> >> For example: While continuing to cylinder-align the logical partitions, this >> is only reflected by the CHS values and not by the corresponding LBA sector >> numbers. CHS and LBA sectors get out of sync because of some wired mix of >> doing LBA and CHS calculation. A problematic line is for example: >> >> https://github.com/boeckmann/fdisk/blob/2c7da2178c097792c3642e73eeb319330e122c71/SOURCE/FDISK/PCOMPUTE.C#L189 >> >> Here the relative starting sector gets set unconditionally. But that is >> wrong in case the extended partition does not start on a cylinder boundary >> while the logical still gets aligned to it. >> >> I must confess that I do not really know how to solve this issue without >> being in danger to completely break everything and want to ask: >> >> a) If someone has an idea of a clever solution without rewriting the (sadly >> large) calculation routines. >> >> b) If it would be ok (at least as an interim solution) to make FDISK refuse >> handling disks with such type of partition layout, because the user must >> have another partition manager to create such layouts anyway. While not >> being optimal, I think this is better than letting FDISK break things. >> >> Greetings, Bernd > The reason why partition boundaries are aligned on cylinder boundaries > is that a lot of other OSes also rely on that. any example of this? I don't any (not completely braindead) operating system would rely on that; it's just the way that FDISK and friends place partitions on the disk. I don't think FORMAT or file systems ever relied on cylinder boundary alignment; at least they shouldn't. Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
> Am 01.03.2023 um 18:08 schrieb Ralf Quint : > >> b) If it would be ok (at least as an interim solution) to make FDISK refuse >> handling disks with such type of partition layout, because the user must >> have another partition manager to create such layouts anyway. While not >> being optimal, I think this is better than letting FDISK break things. After thinking a little bit more about it I no longer consider it necessary to refuse handling of the whole disk, because the errors are not triggered on primary partitions. But I would put the logical partitions inside an inappropriately aligned extended partition and the extended itself in a „read only“ mode to prevent messing up the layout. At least until someone comes up with a better solution... Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
On 3/1/2023 8:22 AM, Bernd Boeckmann via Freedos-devel wrote: Hello, I am now reaching a state where I think that FDISK not any longer breaks the partition layouts created by itself. However, there is at least still one MAJOR flaw when dealing with partition layouts created by other partition managers: If there exists an extended partition with a start address not aligned to cylinder boundaries, the position and size determination for logical drives is completely messed up. For example: While continuing to cylinder-align the logical partitions, this is only reflected by the CHS values and not by the corresponding LBA sector numbers. CHS and LBA sectors get out of sync because of some wired mix of doing LBA and CHS calculation. A problematic line is for example: https://github.com/boeckmann/fdisk/blob/2c7da2178c097792c3642e73eeb319330e122c71/SOURCE/FDISK/PCOMPUTE.C#L189 Here the relative starting sector gets set unconditionally. But that is wrong in case the extended partition does not start on a cylinder boundary while the logical still gets aligned to it. I must confess that I do not really know how to solve this issue without being in danger to completely break everything and want to ask: a) If someone has an idea of a clever solution without rewriting the (sadly large) calculation routines. b) If it would be ok (at least as an interim solution) to make FDISK refuse handling disks with such type of partition layout, because the user must have another partition manager to create such layouts anyway. While not being optimal, I think this is better than letting FDISK break things. Greetings, Bernd The reason why partition boundaries are aligned on cylinder boundaries is that a lot of other OSes also rely on that. Some don't. That's why you can't just change that behavior without creating problems elsewhere. So this needs to be taken into account when calculating LBA. And specially today, there is no reason to whine about a couple dozen sectors or so. Tread carefully, there be dragons... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hello, I am now reaching a state where I think that FDISK not any longer breaks the partition layouts created by itself. However, there is at least still one MAJOR flaw when dealing with partition layouts created by other partition managers: If there exists an extended partition with a start address not aligned to cylinder boundaries, the position and size determination for logical drives is completely messed up. For example: While continuing to cylinder-align the logical partitions, this is only reflected by the CHS values and not by the corresponding LBA sector numbers. CHS and LBA sectors get out of sync because of some wired mix of doing LBA and CHS calculation. A problematic line is for example: https://github.com/boeckmann/fdisk/blob/2c7da2178c097792c3642e73eeb319330e122c71/SOURCE/FDISK/PCOMPUTE.C#L189 Here the relative starting sector gets set unconditionally. But that is wrong in case the extended partition does not start on a cylinder boundary while the logical still gets aligned to it. I must confess that I do not really know how to solve this issue without being in danger to completely break everything and want to ask: a) If someone has an idea of a clever solution without rewriting the (sadly large) calculation routines. b) If it would be ok (at least as an interim solution) to make FDISK refuse handling disks with such type of partition layout, because the user must have another partition manager to create such layouts anyway. While not being optimal, I think this is better than letting FDISK break things. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi, On Tue, 28 Feb 2023 at 20:31, Eric Auer wrote: > > PS: Interesting that Bing ChatGPT answers Aitor using his own > mails, does it at least include some thanks to the author? :-) > Lol it does not, but it links to the log of pages, etc. where it took the answers from. That's how I found out... Aitor ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi Eric, > Now I would like to know how long each of those bugs has been > in FDISK, can you see that in change logs or by comparing your > version to various older versions? It must have been ages :-o I will try to find out and leave a note in CHANGES.md for all critical (potential data loss) errors since when the error exists. In the last hour I found a new bug: Critical: Fix a partition location and size calculation error triggered when a new logical partition is created after deleting the first logical (since at least 1.2.1) It was a one liner to fix but hard to spot: https://github.com/boeckmann/fdisk/commit/95e102270117b4d79430433da1948b31d8c35947 The error was that pDrive->ptr_ext_part is a pointer to the extended partition itself and not a pointer to the logical drive, so the test if the logical partition was empty returned always returned false even it was actually true. After replacing with pDrive->log_drive[0] it seems to work correctly and to me makes logically sense. Would be glad if someone could double check. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi Bernd, thank you for your work on FDISK! Version 1.3.5 (unreleased) -- - CRITICAL: Fix FDISK loading wrong head and sector values from MBR if operating in LBA mode. The previous incorrect behaviuor was hardcoding them to cylinder boundaries instead of calculating them from LBA address, resulting in corrupt partition tables especially if used in combination with other disk utilities. - CRITICAL: Fix different calculation errors leading to overlapping partitions, unnessessary free space between them, or partitions exceeding the end of the disk. - CRITICAL: Fix a bug resulting in detecting non-existant extra cylinders if detection of extra cylinders is enabled. Now I would like to know how long each of those bugs has been in FDISK, can you see that in change logs or by comparing your version to various older versions? It must have been ages :-o Regards, Eric PS: Interesting that Bing ChatGPT answers Aitor using his own mails, does it at least include some thanks to the author? :-) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi Rugxulo, thanks for the advice! > Is makefile.bor still maintained? Do you still (also) support building > it with that toolset (presumably freeware-ish TC++ 1.01 would work)? Yes! At the moment I have it compiling with Borland C++ 3.1, Turbo C++ 3.0 and Open Watcom 1.9. While mainly developing under Watcom I think it is a good idea to have it compile with different toolchains. Helps finding bugs. However, the makefile I started working on did not mention Turbo C++ 1.01, so I did not test that. If someone requests Turbo C++ 1.01 support I will see what I can do. GCC IA-16 support could also be desirable. > it seems you still use NASM (instead of WASM). Seems redundant > (no offense). I have not touched the NASM code yet. I could change the code to assemble under WASM, but because I plan to still support the Borland toolchains I am not aware of any benefit that would bring. > 2. "if exist *.OBJ @rm *.OBJ" is unnecessary, and you should be able > to delete multiple files with Wmake's built-in "rm", e.g. "rm -f *.obj > *.err *.lnk" with no error messages if not found. > > 3. Oh! And %UPX% is possibly a bad variable name since I think that's > what the environment variable is also named, so that will override any > internal makefile variable by default (if the user has set it). I > recommend "PACKER" and "PACKERFLAGS", but this is not majorly > important. Done as you suggested. > 1. Invoking TLINK with a toolset path is unnecessary. You can use > "tcc" (or bcc) to link as well. > 2. You also don't need to manually create temporary linker response > files. (I forget exactly, but it's something like @&&^ ... ^ to do it > automatically.) > Regarding OpenWatcom: > > * https://github.com/boeckmann/fdisk/blob/master/SOURCE/FDISK/MAKEFILE.WAT > > 1. Again, you don't need to manually create a temporary linker > response file. Try using "LD = *wlink" instead, it will automatically > handle long command lines. I guess it is a thing of preference, but at least for Watcom I actually like the generation of separate linker files. Nevertheless dropping it at least for Borland is perhaps a good idea if that removes the need for specifying the toolchain installation path. I will try to change that. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi, On Sun, Feb 26, 2023 at 1:07 PM Bernd Boeckmann via Freedos-devel wrote: > > in the last two weeks I ported Free FDISK to Watcom C and started fixing the > bugs people mentioned > at the bttr forum and in the issue trackers. Great news! Thanks a ton for your work on this. BTW, it seems you still use NASM (instead of WASM). Seems redundant (no offense). > For people wanting to track the progress, I am doing the development at the > following repository: > https://github.com/boeckmann/fdisk. > > I will make merge requests to upstream https://github.com/fdos/fdisk in > regular intervals > > If you want something to be changed please send me an e-mail. I will try to > implement it if time permits it. Is makefile.bor still maintained? Do you still (also) support building it with that toolset (presumably freeware-ish TC++ 1.01 would work)? * https://github.com/boeckmann/fdisk/blob/master/SOURCE/FDISK/MAKEFILE.BOR 1. Invoking TLINK with a toolset path is unnecessary. You can use "tcc" (or bcc) to link as well. 2. You also don't need to manually create temporary linker response files. (I forget exactly, but it's something like @&&^ ... ^ to do it automatically.) See here for an example: * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/n16tcmak.zip Regarding OpenWatcom: * https://github.com/boeckmann/fdisk/blob/master/SOURCE/FDISK/MAKEFILE.WAT 1. Again, you don't need to manually create a temporary linker response file. Try using "LD = *wlink" instead, it will automatically handle long command lines. 2. "if exist *.OBJ @rm *.OBJ" is unnecessary, and you should be able to delete multiple files with Wmake's built-in "rm", e.g. "rm -f *.obj *.err *.lnk" with no error messages if not found. 3. Oh! And %UPX% is possibly a bad variable name since I think that's what the environment variable is also named, so that will override any internal makefile variable by default (if the user has set it). I recommend "PACKER" and "PACKERFLAGS", but this is not majorly important. Again, here's an example "makefile.wcd" of mine (but ignore the older Borland makefile in there): * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/nasm16.zip ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
> However, when the disk already has a partition and is full… > > fdisk 1 /prio:2000 ; no error, no partition created, exit errorlevel 0 > fdisk 1 /pri:100,100 ; divide error, no partition created, exit errorlevel 3 Nice finding! Fixed in https://github.com/boeckmann/fdisk/commit/02990596691474cf93fb64fbdf13b12bffec47d0 > Should be good. Guess we will find out on Wednesday. Yes looks good, I will try it out :-) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi Bernd, > On Feb 27, 2023, at 12:57 PM, Bernd Boeckmann via Freedos-devel > wrote: > > >> Am 27.02.2023 um 17:28 schrieb jer...@shidel.net: >> >> I think I will go with a max partition of 2GB (FAT16) on real hardware and >> the entire disk (FAT32) inside Virtual Machines. > > If you want it to be FAT-16 I would suggest not doing /PRIO:2048 but instead > /PRIO:2047 or even less, because for the common CHS geometry .../254/63, 2048 > MB gets rounded up to 2055 MB. And that is beyond the maximum size of > „compatible“, 64 sectors per cluster, FAT-16 partitions. Just going to use 2000. After all, based on how hard drive manufacturers calculate sizes a 2GB hard disk would only be about 1907mb. > > FDISK always rounds the user specified size up to the next cylinder boundary. > It does not restrict the partition size but unconditionally sets the > partition type to FAT-16 if you specify /PRIO. So depending on the behaviour > of the format utility, it would either create a FAT-16 with a cluster size of > 128 sectors or waste space at the end of the partition. > > Greetings, Bernd After a little more testing, here is an interesting wrinkle found while experimenting on a 500mb VM hard drive. fdisk 1 /clear /prio:2000 ; no problem, creates a 500mb FAT16 fdisk 1 /clear /pri:100,100 ; no problem, creates a 500mb FAT32 However, when the disk already has a partition and is full… fdisk 1 /prio:2000 ; no error, no partition created, exit errorlevel 0 fdisk 1 /pri:100,100; divide error, no partition created, exit errorlevel 3 Since the installer first tests for partitions and only auto-partitions an empty drive, this is probably not a big problem. Unless for some reason, FDISK cannot create the partition for some unknown reason. Anyhow, I’ve implemented the partitioning changes in both installers. Basically, their new logic is something like this: if AnyPartitions(drive) = true then begin FDISK drive end else begin If IsVirtualMachine = true then begin FDISK drive /PRI:100,100 end else begin FDISK drive /PRIO:2000 end if ErrorOccured = true then begin FDISK drive end end REBOOT Should be good. Guess we will find out on Wednesday. :-) Jerome ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
> Am 27.02.2023 um 19:31 schrieb jer...@shidel.net: > > Using your example, I think it would be easier for a user to understand as: > > fdisk 1 /clear /pri:2048 /ext:max /log:4096 /log:max > I agree and implemented it as you suggested. The MAX quantifier now internally is the same as the 100,100 thing. https://github.com/boeckmann/fdisk/commit/1933d8723a10ccf1128e5e7181f2aa76001d7756 /? help screens should get some overhaul. I will take care of it when I am through with bug fixing. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
> On Feb 27, 2023, at 12:02 PM, Bernd Boeckmann via Freedos-devel > wrote: > >> Seriously, thank you. :-) > > Glad I could help :-) > >> On a side note: It might be nice to support '/prio:max’ and '/pri:max’. > > > Shouldn’t do /pri:100,100 the trick? Yep, works fine. > The ,100 indicates that the first value is to be interpreted as a percentage. > If you want to specify the size in MB you must NOT give the ,100 as a second > argument. As an example: > > fdisk 1 /clear /pri:2048 /ext:100,100 /log:4096 /log:100,100 > > Will wipe the disk, create a ~2048 MB primary partition, an extended > spawning the rest of the disk and two logical partitions, the first ~4096 MB > in size and the second filling the rest of the extended partition. Interesting, the HELP simply says: Creating primary partitions and logical drives: sizes in MB or [,100] in percent /PRI:[,100] [/SPEC:] [drive#] Creates a primary partition. Using your example, I think it would be easier for a user to understand as: fdisk 1 /clear /pri:2048 /ext:max /log:4096 /log:max But, that installer will just use 100,100 and not worry about it. :-) Jerome > > Greetings, Bernd > > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
> I'm not sure if this fdisk can already do that, but additionally it > would also be very useful if it could align partitions to 4k rather > than 63 sectors to lower wear on flash drives (SSD, CompactFlash). You can certainly make a case for aligning things on 4k boundaries on both modern and old disks, but I don't think it has anything to do with wear on non-magnetic disks. From what I understand, much like magnetic disks a non-magnetic disk can (theoretically) be read a virtually infinite number of times -- it's only the writing that wears things out. And again, much like modern magnetic disks, even if the native physical alignment is 4k (instead of 512 like the older disks) the firmware in the disk handles that all automatically. That is, if you are modifying only a single 512-byte sector the firmware does a read-modify-write sequence (it reads the entire 4k physical sector the 512-byte virtual sector is part of, modifies the part that's changed, and then writes the entire 4k sector back to disk). That's only one read and one write operation and the write is (supposedly) the only one that causes wear. If you use some sort of disk caching program (especially one that caches the writes) it gets more complicated, but in general the caching makes things more efficient both in terms of speed and wear. I think the justification for 4k alignment would come from speed rather than wear, since if cluster alignment and physical sector alignment don't match writing a _cluster_ can take multiple writes (but not to the _same_ physical sector so wear doesn't really come into play). On older magnetic disks, the reason they aligned things on odd-numbered sector boundaries was not for wear but for speed. The old disks would sometimes needed to physically move the head to a new location and wait for the disk to spin around again before it could start reading or writing. If that happened in the middle of a cluster read/write it slowed things down and did cause wear on the head movement mechanism. But odd-numbered sectors never aligned with cluster sizes of more than one sector anyway, so the alignment never really made much (if any) difference in terms of wear or speed. In reality, 4k alignment is just as good as odd-numbered alignment for both speed and wear on older disks, and 4k alignment is much better on new disks. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
> Am 27.02.2023 um 17:28 schrieb jer...@shidel.net: > > I think I will go with a max partition of 2GB (FAT16) on real hardware and > the entire disk (FAT32) inside Virtual Machines. If you want it to be FAT-16 I would suggest not doing /PRIO:2048 but instead /PRIO:2047 or even less, because for the common CHS geometry .../254/63, 2048 MB gets rounded up to 2055 MB. And that is beyond the maximum size of „compatible“, 64 sectors per cluster, FAT-16 partitions. FDISK always rounds the user specified size up to the next cylinder boundary. It does not restrict the partition size but unconditionally sets the partition type to FAT-16 if you specify /PRIO. So depending on the behaviour of the format utility, it would either create a FAT-16 with a cluster size of 128 sectors or waste space at the end of the partition. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
On Mon, 27 Feb 2023 16:55:31 +0100
tom ehlert wrote:
> I hate feature flags as they must be decovered first.
>
> hiding it behind
>
>if lba_supported_by_disk and
> total_disk_size > 8,4 GB // max total size for CHS addressing
> {
> place partitions on 4K boundary
> }
>
> Tom
Hi,
Unless CompactFlash cards do some firmware magic to solve the 4k
alignment problem that I'm not aware of, there are plenty of
CompactFlash cards that are smaller than 8.4GB. This may also be
true of SD cards. util-linux fdisk detects if a mass storage device is
flash or not and automatically aligns to 4K as appropriate. But this
may be much harder to do with DOS/older computers. So an unconditional
switch like /4K would be better here.
--
WWW: https://metalpunks.info
GPG: C90CAB7122AC1231
pgp9zmhDtni4x.pgp
Description: OpenPGP digital signature
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
> Seriously, thank you. :-) Glad I could help :-) > On a side note: It might be nice to support '/prio:max’ and '/pri:max’. Shouldn’t do /pri:100,100 the trick? The ,100 indicates that the first value is to be interpreted as a percentage. If you want to specify the size in MB you must NOT give the ,100 as a second argument. As an example: fdisk 1 /clear /pri:2048 /ext:100,100 /log:4096 /log:100,100 Will wipe the disk, create a ~2048 MB primary partition, an extended spawning the rest of the disk and two logical partitions, the first ~4096 MB in size and the second filling the rest of the extended partition. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi, > On Feb 27, 2023, at 7:27 AM, Bernd Boeckmann via Freedos-devel > wrote: > > Hi Jerome, > >> Am 26.02.2023 um 23:31 schrieb Jerome Shidel : >> >> Unfortunately, the current FDISK performs this task be creating a bunch of >> 2GB partitions. This tends to annoy users installing on real hardware with >> very large disks. > > Yes at the moment it sadly is hardcoded to creating partitions of 2048 MB in > size. > >> I propose two additional options that could be added to modify what occurs >> when partitions are automatically created. >> >> First, the ability to only create a single partition automatically. Leaving >> the the remainder of the disk unallocated. >> >> Second, an option to tell it to use FAT32 and create the partitions as large >> as possible. >> >> The options could be used together or separately along with the >> auto-partition option. > > FDISK should already be able to create primary partitions etc. from the > command line. Therefore suggest the following: > > fdisk /ifempty /pri: … We learn something new every day… Where were you about 7 or 8 years ago when I was creating the installer? I had not been used FreeDOS much up to then and it would have been great to have this simple answer at that time. Seriously, thank you. :-) I just did a simple test inside a VM with a 32gb drive. Booted T2302 Live CD and ran: fdisk /pri:8589934592,100 1 Invalid partition size specifed ; should be ‘specified' Program terminated fdisk /pri:8589934591,100 1 ; no error or other messages displayed I ran fdisk and checked. Entire drive used with single partition. Good enough. Now lets see if I can squeeze an update to both installers out the door before the next OS Interim Build (T2303) in just under 48 hours. Not difficult to implement. But, I’m tied up with other things at the moment. I will try to work it in later today or tomorrow. If it is not ready for T2303, then definitely by T2304. I think I will go with a max partition of 2GB (FAT16) on real hardware and the entire disk (FAT32) inside Virtual Machines. On a side note: It might be nice to support '/prio:max’ and '/pri:max’. > The proposal here is /ifempty. That would make FDISK terminate if the > partition table is not empty, and in effect ignoring all the arguments behind > it. So the partitions are conditionally created only if the disk is > „uninitialized“. > > Perhaps the FreeDOS installer could make the user choose between a few > different partition layouts if it detects that the partition table is empty. > If you need a way to make FDISK tell the installer if the disk is empty give > me a note. I can make FDISK return that info via exit code in a fdisk > /isempty like call. > > The /auto option then could for compatibility reasons stay as it is. > > Greetings, Bernd At present, the installer looks to see if there is an existing usable DOS partition. If there is not and if there are no partitions at all, it auto-partitions the drive. If there is not and any partitions exist, it executes fdisk and lets the user worry about the problem. It performs the check for partitions by using FDISK and parsing the returned information about the drive. While having an /isempty option is not required at present, it would be much better to have FDISK perform the test instead of the installer. That way in the future, no problems occur if the return information from FDISK is modified in such a way that the installer cannot figure out. That would simplify that portion of the installer to just… Hey, try and make a partition if it is empty. Failed? Ok, run then fdisk. It would also permit the installer to “auto-partition” an empty drive when it was not able to create a ram disk. Which is required to parse the return information by the batch based installer when no existing usable drives are ready. :-) Jerome ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hallo Herr Bernd Boeckmann via Freedos-devel,
am Montag, 27. Februar 2023 um 13:07 schrieben Sie:
>> Am 27.02.2023 um 07:26 schrieb Deposite Pirate :
>>
>> I'm not sure if this fdisk can already do that, but additionally it
>> would also be very useful if it could align partitions to 4k rather than
>> 63 sectors to lower wear on flash drives (SSD, CompactFlash).
> The current behaviour is to always align partitions to cylinder
> boundaries. This may be a multiple of 63 sectors if it corresponds to the
> disk geometry.
> I did not find any option in the source code to force FDISK to use
> other alignment options . All the calculations are done on a
> cylinder basis, and the sector size is hardcoded to 512 bytes.
> Can it be modified with reasonable effort to at least support 4k
> alignment without rewriting 50% of the code? I think yes. One
> solution could be that within the calculated cylinder boundaries one
> could increase the starting sector by at most 7 to force an
> alignment to 4k. That would make the partition start on a 4k
> boundary.
that sounds like a really good idea, and old versions of anyDOS should
also handlethis well.
> I am not sure if it is also necessary to decrease the end
> sector by at most 7 to make the partition size a multiple of 4k, but
> for safety reasons one should consider doing that.
I don't think this would be necessary; I don't think any reasonable
formatter that allows for a starting sector != 0 but not respecting
endsector!= maxsec-1
> This method would have the shortcoming that there can be little
> gaps of at most 15 sectors between the partitions. And I am not sure
> what that change would mean to the compatibility with older DOS
> versions in general, so that should better be hidden behind a feature flag.
I hate feature flags as they must be decovered first.
hiding it behind
if lba_supported_by_disk and
total_disk_size > 8,4 GB // max total size for CHS addressing
{
place partitions on 4K boundary
}
Tom
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi Jerome, > Am 26.02.2023 um 23:31 schrieb Jerome Shidel : > > Unfortunately, the current FDISK performs this task be creating a bunch of > 2GB partitions. This tends to annoy users installing on real hardware with > very large disks. Yes at the moment it sadly is hardcoded to creating partitions of 2048 MB in size. > I propose two additional options that could be added to modify what occurs > when partitions are automatically created. > > First, the ability to only create a single partition automatically. Leaving > the the remainder of the disk unallocated. > > Second, an option to tell it to use FAT32 and create the partitions as large > as possible. > > The options could be used together or separately along with the > auto-partition option. FDISK should already be able to create primary partitions etc. from the command line. Therefore suggest the following: fdisk /ifempty /pri: ... The proposal here is /ifempty. That would make FDISK terminate if the partition table is not empty, and in effect ignoring all the arguments behind it. So the partitions are conditionally created only if the disk is „uninitialized“. Perhaps the FreeDOS installer could make the user choose between a few different partition layouts if it detects that the partition table is empty. If you need a way to make FDISK tell the installer if the disk is empty give me a note. I can make FDISK return that info via exit code in a fdisk /isempty like call. The /auto option then could for compatibility reasons stay as it is. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
> Am 27.02.2023 um 07:26 schrieb Deposite Pirate : > > I'm not sure if this fdisk can already do that, but additionally it > would also be very useful if it could align partitions to 4k rather than > 63 sectors to lower wear on flash drives (SSD, CompactFlash). The current behaviour is to always align partitions to cylinder boundaries. This may be a multiple of 63 sectors if it corresponds to the disk geometry. I did not find any option in the source code to force FDISK to use other alignment options . All the calculations are done on a cylinder basis, and the sector size is hardcoded to 512 bytes. Can it be modified with reasonable effort to at least support 4k alignment without rewriting 50% of the code? I think yes. One solution could be that within the calculated cylinder boundaries one could increase the starting sector by at most 7 to force an alignment to 4k. That would make the partition start on a 4k boundary. I am not sure if it is also necessary to decrease the end sector by at most 7 to make the partition size a multiple of 4k, but for safety reasons one should consider doing that. This method would have the shortcoming that there can be little gaps of at most 15 sectors between the partitions. And I am not sure what that change would mean to the compatibility with older DOS versions in general, so that should better be hidden behind a feature flag. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
On Sun, 26 Feb 2023 17:31:12 -0500 Jerome Shidel wrote: > Hi Bernd, > > Since you are working on fixing and improving FDISK, there are two > features that would be great to add for end users. > > During the installation of FreeDOS, when no partitions are present, > the installer will try to use FDISK to automatically partition the > drive. > > Unfortunately, the current FDISK performs this task be creating a > bunch of 2GB partitions. This tends to annoy users installing on real > hardware with very large disks. > > I propose two additional options that could be added to modify what > occurs when partitions are automatically created. > > First, the ability to only create a single partition automatically. > Leaving the the remainder of the disk unallocated. > > Second, an option to tell it to use FAT32 and create the partitions > as large as possible. > > The options could be used together or separately along with the > auto-partition option. > > I think the first option would be enough for most users most of the > time. A 2gb DOS partition is huge. However if need be, the user could > create an additional single large partition at a later time. > > However when installing to a virtual machine, the installer could > then just partition the entire virtual disk as a single partition. > > :-) Hi, I'm not sure if this fdisk can already do that, but additionally it would also be very useful if it could align partitions to 4k rather than 63 sectors to lower wear on flash drives (SSD, CompactFlash). It is always said to use Linux's fdisk for that, but that's not as fast and convenient (booting with a CD or PXE) as doing it with a DOS bootable floppy on older computers. -- WWW: https://metalpunks.info GPG: C90CAB7122AC1231 pgpkmb7SnWsRv.pgp Description: OpenPGP digital signature ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi Bernd, Since you are working on fixing and improving FDISK, there are two features that would be great to add for end users. During the installation of FreeDOS, when no partitions are present, the installer will try to use FDISK to automatically partition the drive. Unfortunately, the current FDISK performs this task be creating a bunch of 2GB partitions. This tends to annoy users installing on real hardware with very large disks. I propose two additional options that could be added to modify what occurs when partitions are automatically created. First, the ability to only create a single partition automatically. Leaving the the remainder of the disk unallocated. Second, an option to tell it to use FAT32 and create the partitions as large as possible. The options could be used together or separately along with the auto-partition option. I think the first option would be enough for most users most of the time. A 2gb DOS partition is huge. However if need be, the user could create an additional single large partition at a later time. However when installing to a virtual machine, the installer could then just partition the entire virtual disk as a single partition. :-) Jerome > On Feb 26, 2023, at 2:06 PM, Bernd Boeckmann via Freedos-devel > wrote: > > Hello, > > in the last two weeks I ported Free FDISK to Watcom C and started fixing the > bugs people mentioned at the bttr forum and in the issue trackers. > > For people wanting to track the progress, I am doing the development at the > following repository: https://github.com/boeckmann/fdisk. > > I will make merge requests to upstream https://github.com/fdos/fdisk in > regular intervals and uploaded an interim build (compiled with Open Watcom) > at https://nextcloud.iww.rwth-aachen.de/index.php/s/egSe4Jyj9zx72ag > > I touched the source at many places, so I can not rule out that I have > introduced new bugs but plan to continue working on it. For the moment, > please consider it beta and dangerous. > > If you want something to be changed please send me an e-mail. I will try to > implement it if time permits it. > > User visible changes so far: > > Version 1.3.5 (unreleased) > -- > - CRITICAL: Fix FDISK loading wrong head and sector values from MBR if >operating in LBA mode. The previous incorrect behaviuor was hardcoding >them to cylinder boundaries instead of calculating them from LBA address, >resulting in corrupt partition tables especially if used in combination >with other disk utilities. > - CRITICAL: Fix different calculation errors leading to overlapping >partitions, unnessessary free space between them, or partitions exceeding >the end of the disk. > - CRITICAL: Fix a bug resulting in detecting non-existant extra cylinders >if detection of extra cylinders is enabled. > - ENHANCEMENT: Warn if user tries to use FDISK with a disk size of >2TB, >because it can not handle it properly. If the user decides to continue >the disk size is truncated to 2TB, making sure nothing bad happens by >some overflowing values. > - ENHANCEMENT: Free FDISK now compiles with Open Watcom C. > > Greetings, Bernd > > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
