dakotacookenmaster / metadisk Goto Github PK

It would be nice if the Disk Simulator showed the queue of pending requests. Might be a nice use of the horizontal space currently going to waste. Maybe even connected to #2, so you see the upcoming requests below the current one.

It would be nice to have a link to the repo on the page so reporting a bug or making a feature request is easy. Perhaps going directly to the Issues page?

It would be nice if the Disk Simulator app showed which sector it's seeking, reading, or writing.

I suspect the NUL character and other special characters in the weird old IBM character set are messing things up. I'd rather have nicely lined up text than the fancy characters.

When viewing a "file" that's actually a directory, it would be nice to have a special viewer that shows directory entries, like the inode block viewer does. At the very least a little documentation on the structure of directory entries would be nice.

1 kiB blocks, 1 sector per block, 8 blocks per disk, 1 track. With 32 B/inode and 1 inode block (both correctly reported), there should be 32 inodes. The system reports 64.

It would be useful to have the block number showing somewhere in "File System Block Layout" view (Superblock = 0, Inode Bitmap = 1, etc.). This would help identify where each block pointer in an inode is actually pointing.

When the disk is full, I would expect it to give an error when I try to add another file, but it simply gives the popup message, "Filenames must be 13 characters or less".
This error was produced when I tried to enter a longer filename, and continued to be popped up every time I created a new file for the disk. When the disk was full it would still allow me to go through the process of creating a file, pop up the filename length error, and not add the file.

In the Binary view of bitmaps (in the FSV), the lowest-numbered bit is shown as the most significant bit. Thus, a disk that's only using the first 4 data blocks has a value of "11110000" in the first byte of the data bitmap. That reads nicely left to right, but it's fairly unusual to have the MSb correspond with the lowest-numbered item. I'm OK leaving it this way, but the documentation should include a little diagram that makes that clear.

With a disk that has 1 KiB sectors, 1 sector per block, and 8 blocks per disk (on 1 track), the system allocates a single block for the inode bitmap (which is correct). It then shows a paging widget at the bottom of the view, which shows "< 1 2 3 4 5 ... 31 >". I confirmed that the last page is short of the 8192 bits that should be shown. This seems to be the case regardless of the size of the disk and the number of inode blocks.

The "Fast" speed setting has the disk spinning at about 5 RPM, which still feels very slow. This is on my new laptop, which should be able to handle pretty much anything you throw at it for 2D graphics, so I know it's not the platform specifically.

This is on Chrome, where I have a lot of windows and tabs open (though most of them are suspended). Trying the same thing on a fresh copy of Edge with a single tab open has the disk spinning at about 10 RPM. Is that affecting the speed of the animation? It really shouldn't be, as I have plenty of CPU and GPU capacity available, and Chrome runs each tab in a separate process, AFAIK.

It appears to be connected to having an external display with a slower refresh rate (30 Hz, in my case). Edge showed similar behavior--faster on my laptop's display, slower on my TV. Firefox seemed to keep the same speed on both (fast enough).