| |
SQ6BOT > PSBBS 12.07.96 00:03l 69 Lines 3267 Bytes #-10216 (0) @ WW
BID : B76SR6BOX006
Read: GUEST
Subj: Re: File system thoughts
Path: DB0AAB<DB0PV<DB0WGS<OE3XSR<OK0PBX<SP6KBL<SR6BOX
Sent: 960711/1903z @:SR6BOX.#WRO.POL.EU [BayCom-Mailbox [Wroclaw]] BCM1.37b
From: SQ6BOT @ SR6BOX.#WRO.POL.EU (Zipu)
To : PSBBS @ WW
SM0ORB wrote:
> :but more important now is the BBS itself. Up till now I heard no advice
> :about the way of storing messages. So here are some of my thoughts:
> :Messagese cannot be stored in separate files - this eats too much disk
>
> Think about what Hank wrote. The system will take some time to get
> complete and we should aim a few years ahead. Allready today disk space
> is fairly cheap and it will probably get even cheaper. Do all development
> with standard files, one per message, and let the worries about storing
> mail wait a while. Perhaps we won't even have to do anything more.
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.
> : Second thought is making one big file that fills whole disk space.
> :Inside such file we have more flexibility. First possibility is making our
> :own file structure and store messages in our own way - for example with
> NO please. Use standard routines, if someone wants a special file system
> it is not a part of the BBS but a part of the OS.
Here I can agree...
> : Just in this moment I got another idea - I think it's the best one!
> :Each board will have separate directory. In each of such directories
> :there will be something like described in point [1], but NOT AS ONE BIG
> :FILE, but lots of cluster-sized (ex. 16, 32 kB) files. All files joined
> No again. This idea would create a big risk of corrupting the disk space.
> Remember all pointers must be saved to disk in case of a system crash.
...but here I cannot. Pointers _will_ be saved on the disk. And even
if they become corrupted - they can be restored. Each pointer record
can contain either same offset, or offset, name, date, sender, etc.
I see no risk of corrupting disk space - you don't do anything inside the
file chain, just delete files containing earlier messages (from the
beginning) and add new (to the end). Only pointer file has to be rewritten.
When it contains only offsets, then for board with 5000 messages
it will occupy only 20 kB of disk space.
Index file can contain no names, titles, senders, etc. - I think it will
work fast, when BBS reads offset value, jumps to choosen point of
file-chain and reads one line.
Anyway if it isn't enough fast - index file would be a bit larger.
> : So what do you think now? Can I start making read/list/send
> :function using this disk storage scheme? Or it requires improving?
> Start writing using ordinary file I/O routines.
I'll start writing I/O functions using ordinary file structure.
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.
When he has lack of disk space and wants to take a risk (I think there
wouldn't be any risk) - he will choose file-chain. Otherwise - ordinary
file structure.
> :I'll send you sources update soon. Should I send exec also?
> :(BTW: it should be compiled using huge memory model).
> Sure send the exec too, maybe someone is interested in testing but have
> no compiler.
Done.
> /Anders
73, Peter
Read previous mail | Read next mail
| |
