fkk@stasys.UUCP (Frank Kaefer) (12/18/89)
Dear OS-9 people! I have an annoying problem with the OS-9 filesystem. Every day I get the message: Error #000:217 (E$SLF) File segment list is full. A file has become too fragmented to accomodate further growth. This can occur on a nearly full disk, or one whose free space has become scattered. The simplest way to solve the problem is to copy the file, which should move it into more contiguous areas. from newsinput (notes) when it tries to insert a new article in the notesfile. I have formated the harddisk with 8-sector clusters, so I don't get error 217 too often. But I think there should be another solution to the problem (copying the file can only prevent err. 217 for a little while). Any help appreciated. Frank. -- +--------------------------------+ Keep your night light burning | Frank Kaefer | fkk@stasys.UUCP | I'll come through wind and rain | (Compuserve: 72427,2101) | Keep your night light burning | (BIX: fkaefer) | I'll be with you once again +--------------------------------+ [On A Storyteller's Night - Magnum]
ram@floenz1.UUCP (Reimer Mellin) (12/23/89)
In article <1123100003@stasys> fkk@stasys.UUCP (Frank Kaefer) writes: } from newsinput (notes) when it tries to insert a new article in the } notesfile. I have formated the harddisk with 8-sector clusters, so I } don't get error 217 too often. But I think there should be another configure your hard-disk descriptor !!! a nice patch is PD_SAS (see sys.l), change it to 64 or $40 or whatever u like .... (see tech. man. for further explanations). BTW: I have abandonend the 8-sector cluster since they eat up too much disk-space .... Greetings Reimer Mellin ps: no disclaimer
joseph_cheek@i-core.UUCP (Joseph Cheek) (01/03/90)
In article <1123100003@stasys>, fkk@stasys.UUCP (Frank Kaefer) writes: > >Dear OS-9 people! > >I have an annoying problem with the OS-9 filesystem. Every day I get the >message: Error #000:217 (E$SLF) File segment list is full. > A file has become too fragmented to accomodate further growth. This can > occur on a nearly full disk, or one whose free space has become scattered. > The simplest way to solve the problem is to copy the file, which should > move it into more contiguous areas. You might want to check out a utility called 'File System Repack', sold by Burke & Burke, of Renton, WA. It is sold for CoCo OS-9 Level Two microcomputers, but they might have a version for OSK. If you want to check into it, you can contact them at: Burke & Burke P.O. Box 58342 Renton, WA 98058 (206) 235-0917 Hope this can help you. Joseph Cheek (joseph_cheek@i-core.UUCP)
pa1412@sdcc13.ucsd.edu (pa1412) (01/06/90)
In article <1123100003@stasys> fkk@stasys.UUCP (Frank Kaefer) writes:
+
+Dear OS-9 people!
+
+I have an annoying problem with the OS-9 filesystem. Every day I get the
+message:
+
+Error #000:217 (E$SLF) File segment list is full.
+....
+don't get error 217 too often. But I think there should be another
+solution to the problem (copying the file can only prevent err. 217 for
+a little while).
Yeah, re-write RBF and make the last segment table entry be a
pointer to the next segment table block. Then cache all the blocks
on open. Each open will have more time overhead and the new RBF
would take more space but with fast processors speedy SCSI and megs
of ram all problems go away.
Having implemented my own disk OS once a long time ago in a galaxy
far far away I would rather live with someone else slightly limited
product than fix it myself.
But if the Microware gods are listening, I would like a little
rethink in this area.
--
John Clark
jclark@ucsd.edu
pa1412@iugrad2.ucsd.edudavely@mcrware.UUCP (Dave Lyons) (01/09/90)
In article <5936@sdcc6.ucsd.edu> pa1412@sdcc13.ucsd.edu (pa1412) writes: |In article <1123100003@stasys> fkk@stasys.UUCP (Frank Kaefer) writes: | |+don't get error 217 too often. But I think there should be another |+solution to the problem (copying the file can only prevent err. 217 for |+a little while). | |Yeah, re-write RBF and make the last segment table entry be a |pointer to the next segment table block. Then cache all the blocks |on open. Each open will have more time overhead and the new RBF |would take more space but with fast processors speedy SCSI and megs |of ram all problems go away. [stuff deleted] |But if the Microware gods are listening, I would like a little |rethink in this area. |-- |John Clark What you suggest is exactly what is done in OS-9000 RBF. I guess that being the "gods" we are, we forknew that you would suggest this 8^). Actually, with so many people complaining about the 217 problem (inc- luding me) over the years, allowing an unlimited number of segments was one of the major design goals for the new RBF along with sector sizes other than 256 bytes. See Ric Yeates and James Jones article in this space for more info on new features in OS-9000. -- Dave "Not the Apple Guy" Lyons - uunet!mcrware!davely ------------------------------------------------------------------------ "We can't fight you. We're totally weak" - Bill S. Preston, Esq. My employer laughs at my opinions.
joseph_cheek@i-core.UUCP (Joseph Cheek) (01/10/90)
In article <5936@sdcc6.ucsd.edu>, pa1412@sdcc13.ucsd.edu (pa1412) writes: > >Yeah, re-write RBF and make the last segment table entry be a >pointer to the next segment table block. Then cache all the blocks >on open. Each open will have more time overhead and the new RBF >would take more space but with fast processors speedy SCSI and megs >of ram all problems go away. > Reportedly, OS-9000 has unlimited segment-list size. Want to move to OS-9000? 8-)
Grunwald@Weimar.Berkeley.EDU (Grunwald Betr. Tichy) (01/12/90)
The OS9000 RBF looks fine, but there are some changes i would like to hear of. First the segment list should be extended by a segment and not a block, because a segment has much more space. The access attribute interpretation should be changed. It is now possible to have a file with owner access denied and public access allowed. This silly combination should be changed to group access for full UNIX compatibility in that field and beside of that it is a nice feature. The change will have no effect to the rest of us, because the combination is not used. The group/user code should be changed to full 16+16 Bits. This change will affect a lot of utilities and should be therefore announced early, to give programmers time to prepare for the change. The Filemanager should be able to use the elevator strategie on devices with the elevator attribute. The elevator strategie is, to serve all accesses in one direction first, before the direction is changed. As the RBF has an access queue for any driver, this should be entirely possible. For very special realtime tasks you can switch back to the first-come-first-serviced strategie we have now. Another extension i would like is to have the possibility of an access check program. This is a program which gets the path, group, user and at least one extra parameter and returns 1 for permission allowed and 0 for permission denied. The name of the program and the extra parameter should be stored in the file-descriptor sector. You can have very precise access conditions with that feature. (example: game access only outside of working hours, extra passwords for special files (personal files, which have to be protected)). I like OS9 a lot and would be glad over any improvement, but microware should think of changed marketing strategie. With the high prices on any product you have not enough enthusiast, which do the dirty work of nice utilities, which are not to hard to program, but very time intensive. Also i would like to see microware to contact independent developers like Heimsoeth and Borland to port their products to OS9. Especially Turbo-C i much better for normal programs as the microemacs, than Microware C V3.0 that i have. The microware C-Compiler has the actual OS9-libs, but thats not enough now. I hope the thinks are getting better and microware will answer. I think lots of people will await this answer to.
davely@mcrware.UUCP (Dave Lyons) (01/14/90)
In article <1373@iraun1.ira.uka.de> Grunwald@Weimar.Berkeley.EDU (Grunwald Betr. Tichy) writes:
+The OS9000 RBF looks fine, but there are some changes i would like to hear of.
+First the segment list should be extended by a segment and not a block, because
+a segment has much more space.
I'm not exactly sure what you mean by this but let me explain the way it works
and then you can point out where you see the deficiencies. With OS-9000 RBF,
when the segment list in the first file descriptor block fills up, RBF allo-
cates another block. The new block is linked to the first one by LSN "poin-
ters" kept in the last segment entry. Segment lists don't fill up that often
so I think just expanding the list by a block at a time is the most effecient
way to go.
+The access attribute interpretation should be changed.
+It is now possible to have a file with owner access denied and public access
+allowed. This silly combination should be changed to group access for full
+UNIX compatibility in that field and beside of that it is a nice feature.
+The change will have no effect to the rest of us, because the combination
+is not used.
+
+The group/user code should be changed to full 16+16 Bits. This change will
+affect a lot of utilities and should be therefore announced early, to give
+programmers time to prepare for the change.
As far as file attributes go, the field is now 16 bits and there are now bits
for group access and the permission rules have been changed as you have men-
tioned above, i.e. public access allows group and owner access also.
+The Filemanager should be able to use the elevator strategie on devices with
+the elevator attribute. The elevator strategie is, to serve all accesses in
+one direction first, before the direction is changed. As the RBF has an
+access queue for any driver, this should be entirely possible. For very
+special realtime tasks you can switch back to the first-come-first-serviced
+strategie we have now.
I think something like this will definitely be implemented for OS-9000.
+Another extension i would like is to have the possibility of an access check
+program. This is a program which gets the path, group, user and at least one
+extra parameter and returns 1 for permission allowed and 0 for permission
+denied. The name of the program and the extra parameter should be stored in
+the file-descriptor sector. You can have very precise access conditions with
+that feature. (example: game access only outside of working hours, extra
+passwords for special files (personal files, which have to be protected)).
This is an interesting idea.
+I like OS9 a lot and would be glad over any improvement, but microware should
+think of changed marketing strategie. With the high prices on any product you
+have not enough enthusiast, which do the dirty work of nice utilities, which
+are not to hard to program, but very time intensive.
+
+Also i would like to see microware to contact independent developers like
+Heimsoeth and Borland to port their products to OS9. Especially Turbo-C is
+much better for normal programs as the microemacs, than Microware C V3.0 that
+i have. The microware C-Compiler has the actual OS9-libs, but thats not enough
+now.
+
+I hope the thinks are getting better and microware will answer. I think lots of
+people will await this answer to.
Oops, these sound like marketing questions. I hope this tells you
some of what you wanted to know.
Dave
--
Dave "Not the Apple Guy" Lyons - uunet!mcrware!davely
----------------------------------------------------------------------------
"We can't possibly fight you. We're totally weak." - Bill S. Preston, Esq.
My employer laughs at my opinions. Grunwald@Weimar.Berkeley.EDU (Grunwald Betr. Tichy) (01/16/90)
Thank you for your fast answer. That's good news. I hope the new RBF will appear for "normal" OSK too, since OS9000 is just too expensive for me know, although it may be worth the price. I would like to hear one of the marketing people to the questions in this group, if it were possible. Knut Grunwald, Raiffeisenstr. 8, 7551 Elchesheim-Illingen, BRD