Re: [Freedos-kernel] USB-HDD booting and LBA-to-CHS conversion
Hi, it's risky to guess CHS geometry from the MBR, because partitions don't necessarily end at cylinder boundaries. Using CHS internally means to use int13 calls to read/write sectors using CHS values (which Linux does not do). For those the only values that make sense and are safe are the ones compatible with the BIOS, irrespective of what is in the boot sector or MBR! The only reason why CHS is used at all internally for BIOSes that also support LBA is for compatibility with older device drivers (think of cache) that only know about CHS. If all is well, your pendrive's boot sector(s) use the 1021/124/62 geometry. You can always use SYS CONFIG (see docs\sys.txt) with forcelba or set the partition type(s) to an LBA type (0c/0e/0f) (which makes the drive invisible to MSDOS 7) to avoid all the CHS complications. Bart -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
More tests: http://jafile.com/uploads/dos386/perftest.txt unless dos386 describes what program(s) he used on what hardware to produce these results, the data are useless :( ...you can try first writing some dummy data at where the file will end, then close it and re-open (without truncate of course) and do the actual copy. That should bundle the FAT updates and increase performance significantly :-) just did exactly this (for command.com) COPY. unfortunately performance remains the same. for a single drive (that is able to read ~43 MB/sec), using a copy buffer of 60K (Freecom default), copy performs roughly identical, even if the filr is pre-created. Tom -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
- write 1 byte of data at this place Shouldn't it be sufficient to seek to the desired size (as offset), then do a write with length zero there? (Writing with length zero extends or truncates the file to the current seek offset.) - close the file - open file for writing (no truncate) I would suggest not to close and re-open the file. If it does improve the operation's performance, then just committing the file should improve it in the same way. If performance isn't improved by it, the close and re-open sequence can be removed without replacement. Regards, Christian -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
Hi Christian, - write 1 byte of data at this place Shouldn't it be sufficient to seek to the desired size (as offset), then do a write with length zero there? (Writing with length zero extends or truncates the file to the current seek offset.) Possibly, but I wanted to keep things simple and foolproof. - close the file - open file for writing (no truncate) I would suggest not to close and re-open the file. If it does improve the operation's performance, then just committing the file should improve it in the same way. If performance isn't improved by it, the close and re-open sequence can be removed without replacement. Same reason as above. Also, there is a small chance that some implementations of commit are weaker than a full close / open. So I went for the more explicit and possibly safer style here. In any case, the performance penalty of close and re-open in a situation where pre-growing fails to help is very neglible. Eric -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] driveletter assignment?
Is it possible to have the FreeDOS kernel start with driveletter assignment from specific interfaces, or are we stuck with what BIOS offers us? When booting from USB, I've got multiple options: 1) syslinux + memdisk + floppy image 2) syslinux + memdisk + ISO file 3) syslinux + chain.c32 + kernel 4) syslinux + bootsector + kernel What happens is that BIOS presents a USB flash disk as 1st harddisk instead of IDE/SATA harddisk, with consequences of FDISK and driveletter assignments. Situations 3 and 4 as described above can't be helped, BIOS presents USB flash drive as 1st harddisk, FreeDOS kernel recognises it as C: and you happily boot from C: (only very small capacity USB drives used to boot as A:) Situations 1 and 2 however make you end up with booting from a virtual diskette (A:). However BIOS still presents the USB disk as first harddisk, and thus FreeDOS lists it as C:. My question thus is: can driveletter assignment be tweaked to start with primary partitions on SATA/IDE drives, or are we stuck with what BIOS presents us without ability to swap/shift drives? -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
