WB 3.x: Modify block size of built-in RAM disk?

[andreas]

Is this possible at all?
My WB HD has 512k blocks, but by selecting the RAM disk icon and 'Info' from the menu, my RAM disk shows indeed 1k blocks. This should go in line though, so that the RAM disk behaves exactly as my HD, and I'm not doomed to re-calculate blocks every time.

Is there any way to change this somehow, or must I install an external driver?
Thanks for any hints.

[thomas]

The ram disk does not at all behave like a block device. It does not even use blocks.

If you want something in ram that behave like a block device, you should use the RAD.

You can change the block size of your hdd to 1024, though. Would gain some speed either.

Why do you insist on blocks ? Blocks are a virutal unit and might be different from device to device. E.g. CD-ROMs use 2K blocks.

Even with different file systems on HDD a file might need more or fewer blocks depending on how the file system stores directory information.

You should look at the file size. This is the only constant value.

[andreas]

Originally Posted by thomas

The ram disk does not at all behave like a block device.

Indeed, as due to my researches, it has got its very own and independent file system!
(Logical, for as a WB 1.3 user, I obscurely remember that RAM disk was solely possible to use if L:ram-handler was installed. And a handler is a sort of driver.)

Originally Posted by thomas

Why do you insist on blocks ? Blocks are a virutal unit and might be different from device to device. E.g. CD-ROMs use 2K blocks.

Because list displays them as blocks, and not as bytes (unfortunately)
At least list 37.5 (WB 3.0) does that. With 1 file, you can read the file size off the line, but do you always want to ADD file sizes by calculator with 3 or more files? And dir (unlike MS-DOS dir) doesn't display file-sizes, either.

So blocks are a good alternative as long as you can assume they're in constant size (at least with both diskettes and [the gross of] hard drives!)
Or you have to install 3rd-party tools.
Mind you, I have never been a keen mouse-clicker. I still do most of my operations on console, as it's simply faster than clicking your way through it all. Moreover, you will ALWAYS have to change between mouse, keyboard, mouse, keyboard ...

You should look at the file size. This is the only constant value.

If possible yes.

[Duke]

Maybe there are some replacement dir/list tools on aminet which show the total size?

[andreas]

I think there are. Yet I always assume the worst case, and I'm eager to both know a way to do it with tools you have "aboard", and a way to do it with 3rd-party tools.

[thomas]

List shows the file size in bytes. Only the summary shows a number of blocks. But this is a fake anyway. It does not recognise directory blocks.

[andreas]

Originally Posted by thomas

List shows the file size in bytes. Only the summary shows a number of blocks.

Ehhh ... then I was not clear. Of course I meant the *summary*
With a couple of files per list output, I actually do not always want to add up the sizes by hand
Hence the summary is a nice thing ... if the block sizes are equal, which as I've now learnt, are not expected to.

[DrBong]

@Andreas
Perhaps PatchRAM on Aminet might do the trick. Try it and let the rest of us know the results of your (mad) experiments

[andreas]

Would not make much sense.
This tool does not seem to intend changing the block size. It will simply fix the bug of reporting "100% full" of the RAM disk by the system by default.

[Chuckles]

Actually, reporting that RAM: is 100% full really isn't a bug, though it isn't particularly useful either. The capacity of the RAM: device changes dynamically as you copy data into it, so long as there is enough available ram for it to expand. So at any given point in time, it really is 100% full since the space allocated to it is completely taken up with whatever data has been copied to it. The percent full actually makes sense for RAD: though, since its size is predetermined. As for PatchRam, I'm not familiar with it, but it may be doing something as simple as calculating percent full as the ratio of the current size of RAM: vs. the total system ram. If so, it probably should also make some allowance for leaving some amount of that ram free for programs to use. Otherwise when RAM: becomes 100% full, you don't have any free ram available for any other use, and that wouldn't be very useful either.

[andreas]

I know, I know. But the documentation of PatchRAM tells about a "bug". That was not my words

[DrBong]

Originally Posted by andreas

Would not make much sense.
This tool does not seem to intend changing the block size. It will simply fix the bug of reporting "100% full" of the RAM disk by the system by default.

I suggested it more or less as a utility to try as an experiment and hope/pray that it does what you want it to as a happy side-effect Unless there is some old, obscure utility in the Fred Fish collection, I doubt there is a any program that does what you want it to do in this case.