Partition Manager
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 ... 29
Anton Reiser (471) 63 posts |
Just a few word to my solution Raik mentioned. - The SCSIFS module is for the Titanium and PartMan aware (as mentioned by David Pitt). So on my Titanium, with a USB drive, prepared with partiFC, SCSIFS shows two icons, one for every paritions. It works for me, but not extensively tested. And my approach does not work with SCSIFS as boot file system. |
Jon Abbott (1421) 2652 posts |
I’ve updated the OP to detail the main goals and what is in/out of scope as I feel the conversation about PartMan is adding confusion to the purpose of this project. Reading between the lines, PartMan is possibly doing something non-standard and as a consequence hasn’t made it into the main builds. Until that issue is resolved, it can’t be used by this project to create the underlying partitions and should be considered out of scope. |
Richard Walker (2090) 432 posts |
Sounds pretty good to me. The situation with PartMan and the changes tom SCSIFS etc. which have not been merged into the main ROM branch… Well… It sounds like madness. Surely the redefinition of R2 is easy to solve with a new reason code or SWI? Appreciate that this isn’t your issue, Jon, but it would be nice for someone else to maybe take an interest in that bit. |
Chris Hall (132) 3567 posts |
One thing I should like PartMan to dois to be able to extend the size of a filecore partition without wiping the files that are present. |
David J. Ruck (33) 1639 posts |
PartMan wont be able to do that. I’ve looked at the problem of resizing filecore partitions again and again, and always come to the same conclusion – its not worth the risk or the effort. There are two main issues; firstly the middle. Filecore fills from the middle of the disc outwards (to reduce seek times on spinning media), so unlike other filing system which fill from the start, resizing the disc moves the middle and all the files with it. Secondly is the Large File Allocation Unit, Filecore is wedded for life to the value used when creating the disc, if this value changes not only does the alignment of all files on the disc change, but the map must be entirely re-written and the sequence number of every file stored in each director also needs to be changed. The upshot of these two points is that the entire disk has to be re-written, which is a very lengthy process. Not only would it be very difficult to do this in place, but any fault or interruption during the process would probably cause the entire disc to be lost (without even more complexity). Copying everything off, reformatting and copying back is undoubtedly slower, but then uses 100% legal Filecore operations, and should the worst happen, you still have a backup. Either that or port a filing system which supports resizing. |
Jon Abbott (1421) 2652 posts |
I’ve put a mock-up image of how it might look in the OP.
The correct route to take would be for John or Andrew to post the proposed change(s) in the Code review forum. It can then be reviewed, discussed and ensured to not break things when it’s modified and resubmitted.
As David points out, it’s pretty complicated and comes with some major risks, but its something I personally require so plan to implement once I’ve implemented the basic partitioning and formatting. |
Steve Pampling (1551) 8188 posts |
Mock up looks to cover most of the needs of even basic users. I won’t say it’s idiot-proof as that just begs for a better class of idiot to turn up. |
Richard Walker (2090) 432 posts |
Nice screenshot/mockup. The clever bit will be getting drag-and-drop implemented to resize those partitions! I guess it moves along a part of the filesystem bounty. Yes, we still need support in the boot-up and filer icons etc., but this is a nice way of breaking down a large task. |
Jon Abbott (1421) 2652 posts |
I’m going to make a start on the WIMP side first, along with the partition table reader. I’ve yet to figure out some of the basic requirements, such as how to get the physical size of the underlying disc, RISCOS doesn’t implement a MiscOp for it, so it’s a case of resorting to undocumented methods. Does anyone knows a better way of doing things:
As I loathe using undocumented features, I’m going to be slowed down whenever I need to add the documentation to the Wiki. I’ll translate the source into relevant wiki pages before I start coding, as it’s painful at best, trying to code off of someone else’s source because they didn’t document it! SCSI is the worst culprit here. Why devs don’t add documentation when features are added to the OS is beyond me – it should be a requirement before acceptance of the source into the tree. |
André Timmermans (100) 655 posts |
I would have said like the current HForm via (IIRC) the DescribeDisc SWIs, but then is it supposed to describe the physical disc or the partition? |
Julie Stamp (8365) 474 posts |
There is some information on SDFS here.
Does SCSI_Initialise, 2 not do what you want? |
Jeff Doggett (257) 234 posts |
As André says, I think that Hform already has some incantations to read the physical media size. |
Rick Murray (539) 13872 posts |
Given that this will need filesystem support (as traditional filesystems don’t support partitions, those that do have been third party extensions), I think it would be best for DescribeDisc to return information on the partition unless a magic value (“PART”?) is given on entry, in which case it describes the physical media. Extra benefit – if the results are the same both ways, the drive isn’t partitioned… |
Jon Abbott (1421) 2652 posts |
FileCore_DescribeDisc is FileCore specific. I need the physical disc info. It’s also not that useful for describing a FileCore partition until it’s been modified to handle partitions. It can be used on drives that have a FileCore partition that fills the disk.
I’ve no idea, SCSI has never been documented! HForm appears to use it, so its possibly what I’m after. |
Julie Stamp (8365) 474 posts |
That SWI was described in print in 1990. There’s one on Ebay if you fancy it in hardcopy :-) |
Jon Abbott (1421) 2652 posts |
Perfect, thanks for the link. We just need it adding to the wiki. |
André Timmermans (100) 655 posts |
Speaking of physical disk vs partitions, do we have the means to distinguish them? This reminds me of this old topic with suggestions to use conventions like “fsname#partition_nr::drive_nr” or like my suggestion to introduce a disk/device manager API so that there is a central uniform way to manage disks for tools like HForm, DiskKnight maybe even disk icons management. How do existing partition managers handle this stuff? Note for that matter, that since the bounty is underway, we can ask the same to the developer that accepted the bounty. |
Rick Murray (539) 13872 posts |
My experience (Morley SCSI and Simtec IDE) is that the partition looked like a drive. You could have one physical drive in four partitions, or four physical drives. They’d be identical as far as RISC OS was concerned. Reading sectors would read relative to the partition. This is by design, as you really want them to look like separate devices to RISC OS. There is probably some secret undocumented call to read raw sectors, so that the partition table can be accessed and manipulated.
Why does it matter? If you installed the machine, you’ll know how it is laid out. If you didn’t, fire up the formatter/partition tool and see what it says. I recall many years ago using a partitioned drive on an old PC which gave a C drive of around 300MB and a D drive of around 200MB. When I looked inside the machine (cleaning the fans), I was surprised to see only one drive despite the C and D. Don’t know why it was set up this way. |
Alan Adams (2486) 1150 posts |
One good reason for doing this is fragmentation. The swap file, by default, grows and shrinks – a lot. If it’s in the same partition as other active files, usually user files, then it and the user files get badly fragmented. It can also cause operating system file fragmentation. I had a Windows XP computer with 3 partitions – C to boot from, D for just the swap file, and E for user data. As a result it didn’t lose a noticeable amount of performance over a 5 year period. Windows usually (until Win 8 onwards) lose performance steadily over time, for this reason. Win 8 ( I think that’s the first) automatically defragments, which improves things. |
Steffen Huber (91) 1958 posts |
SCSI READ CAPACITY. First the 10 byte cdb version, if that returns the max do the 16 byte variant. Look for the SCSI-3 command set stuff, e.g. SBC-3: https://t10.org/ftp/t10/document.05/05-344r0.pdf |
Steffen Huber (91) 1958 posts |
For existing RISC OS SCSI and IDE solutions, it was never possible to distinguish between a drive and a partition – from the “plain RISC OS” side of thing. The podule firmware looked at block 0 of the device (or the boot block? I don’t remember…) to detect partition data (and this was not interchangeable between different SCSI or IDE podules), and mounted the partitions accordingly. The partition data was usually just a sector (block) offset for the supported 4 to 8 partitions. I think the Power-tec SCSI podule was the only one that understood most other partition schemes and could convert it to its native format. |
Ronald (387) 195 posts |
I ported disktype and added an ADFS reader to it. It detects a wide range of foreign disks by using |
André Timmermans (100) 655 posts |
For Jon it matters. How will he be able to display disks and partitions if he cannot tell the difference between disks and partitions or map the existing partitions ? |
Steve Pampling (1551) 8188 posts |
Is that a port of Christoph Pfisterer’s “disktype 9”? If so it should include the licence file, which is pretty open: just requires the inclusion of the licence file with any copy or altered copy or subset.
Given the abuse of disk access that’s involved on that I wouldn’t blame the software if it had a total epi-fit. |
Ronald (387) 195 posts |
it should include the licence file I have removed the link, It is a straight forward job in GCC should you want to build it yourself. Have limited time until next winter. |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 ... 29