[iyonix-support] Re: File-core limit of 256GB - is it on the list?
- From: jess hampshire <jesshampshire@xxxxxxxxxxxxxx>
- To: iyonix-support@xxxxxxxxxxxxx
- Date: Fri, 19 Mar 2010 18:15:53 +0000
On 19 March 2010 15:10, David J. Ruck <druck@xxxxxxxxxxxx> wrote:
> On 19/03/2010 11:53, jess hampshire wrote:
>> If a new API were defined in advance, wouldn't it be possible to do a
>> longnames style hack? (In the short term at least).
>>
>> i.e. have a module that implements the new api by mapping it to the
>> old one and chopping files that are too big into 2GB chunks. (when a
>> filesystem doesn't support it)
> It's possible, but I don't see the point, the *one* application which needs
> greater than 2GB of data already does it that way using multiple files.
In a way that makes it useless to me. If that chopping it to multiple
files were moved out of the app, and say an FTP client were also able
to use it, then we would have compatibility with the rest of the
world.
> It doesn't solve the problem of handling actual >2GB files which requires
> both a new disc format, and a new API for applications to make use of such
> files.
I don't see why it wouldn't. Filer (unless modified) would see folders
of 2GB files and copy them accordingly. Part of the specification
would need to be that files actually stored as a >2GB file (eg on a
server) would appear to the existing api as though they were a
directory of sub 2GB files.
>> Is it a small number of users? Or is it a case of something else you
>> need a PC for?
>
> For any OS change you need to weight up the cost of development against:-
>
> a) The number of users and applications requiring the feature
> b) The ease of doing it with an easily available alternative
>
> Unfortunately this equation doesn't come out positive for much these days.
But that could be an argument not to do anything.
>> It is a shame, because CD burning is one of the things that RISC OS is
>> good at.
>> it is only the filesystem limits that mess it up for DVDs (and
>> probably blurays too)
>
> Is it? With burn proof drives you get less duds than before, but compared to
> other systems it is a slow and tedious process. Remember only hard drives
> use UDMA on the Iyonix, it has never been implemented for CD/DVDs, they are
> still stuck with slow PIO. So you'd be talking several hours for a BluRay.
Isn't that going to be a chicken and egg situation?
there's no point implementing UDMA for optical drives, because the
filesystem limits the usefulness of DVD burning anyway.And there's no
point implementing big files, since there is no UDMA for it to be any
good for burning.
>>> The real need for>2GB files has been alleviated by the creation of
>>> FAT32FS.
>>> Work like that is a far better use of the very limited development
>>> resources
>>> still left on this platform.
>>
>> Of course what happens when the Fat32 system has a 4GB file on it?
>
> And the number of 4GB files which you can do anything useful with on RISC OS
> is?
About the same as on my 400MHz mac or 300MHz PC, but they are useful
for moving files for the media players I have that can use them. Am I
the only person who uses a media player and a RISC OS machine?
>> (Although should this subject be on this list?)
>
> As long as this is about what development should be a priority of RISC OS 5,
> it falls under the auspices of this list.
>
> Don't get me wrong, I'd love to see a modern disc format and new API on RISC
> OS. But without new hardware capable of both accessing large discs at full
> speeds, and with enough processor power to do something useful with large
> files (such as video), there just isn't enough reason to put in the
> development work with old slow hardware like the Iyonix, and no application
> development to support it.
But would implementing a new api in a module that just chops too big
files up on the host and puts them in a folder, be a major job?
Doing it properly obviously would, but if there's an api, then new
versions of software could use it. (Perhaps sunfish, FTP and
bitorrent), if enough software starts making serious use of it, then
it would make sense to do it properly. If not, at least the
functionality would exist.
--
Jess Hampshire
mailto:jesshampshire@xxxxxxxxxxxxxx
Please reply inline and trim redundant text - I also use mobile email.
---
To alter your preferences or leave the group,
visit //www.freelists.org/list/iyonix-support
Other info via //www.freelists.org/webpage/iyonix-support
Other related posts:
