OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
SM0ORB > PSBBS    18.07.96 08:15l 31 Lines 1197 Bytes #-10166 (0) @ WW
BID : 12368_SK0MK
Read: DO3SMK GUEST
Subj: File storage thoughts
Path: DB0AAB<DB0KCP<DB0ZKA<DB0LX<DB0RBS<DB0SEL<DB0ZDF<DB0SRS<DB0FP<DB0ERF<
      DB0SAW<DB0HRO<OZ4BOX<OZ3BOS<OZ7PAC<OZ3BUL<OZ3BOD<SK6FV<SK6YW<SM6KIK<
      SK6SA<SK6LK<SM7FEJ<SM7TYU<SK7AF<SM5SUH<SK5AS<SK5BN<SK5UM<SK0MK
Sent: 960717/2115Z @:SK0MK.TELGE.AB.SWE.EU #:12368 [JO89TE] $:12368_SK0MK
From: SM0ORB@SK0MK.TELGE.AB.SWE.EU
To  : PSBBS@WW


Sorry for my late comments, but here goes.

:When average message size will be 2 kB and cluster size 16 kB (or even
:32 kB on >1GB disks) - just count how many TIMES more space is wasted.

Who says we will be using FAT as a file system in three years from now.
With newer versions of operating systems there are better ways of handling
big disks. In OS/2 there is HPFS that uses 512 bytes clusters for all disk
sizes. In Windows NT there is NTFS with a similar type of allocation. In
Novell 4.1 there is a function for using left over parts of the clusters
in suballocations for other files. Operating systems must be allowed to
handle this, else we could end up writing a whole OS just for our BBS.

:But as this will be completely separate layer, then way of storing can
:be configurable - and in the future, when both (ordinary and file-chain)
:I/O routines are ready, we would leave the decision to the sysop.

Thats the way it should be, all the way.


Now let's see if i get a chance too lock into this set of code before the
next one comes along (that is the 96-07-08 code :-). At least it does come
so it is not rejected yet.

/Anders


Read previous mail | Read next mail


 18.05.2024 18:50:20lGo back Go up