In article <30a2410517be4a02b7b55c3b7414e8bb.phorum-owner@e-smith.net>, charlieb@e-smith.com (Charlie Brady) wrote:
> This message was sent from: Experienced User Forum.
>
http://forums.contribs.org/index.php?topic=17131.msg66515#msg66515 > ----------------------------------------------------------------
>
> Ed Form wrote:
>
> > It's certainly quicker, and with the major slowdown that you
> > guys have imposed on us with 5.6 update 3 that starts to look
> > very attractive.
>
> Excuse me, Ed, nobody has *imposed* anything on you. If you choose to
> use software which we make available, fine, but nobody is making you use it.
Point taken, and apart from one client system which I installed when I first discovered E-Smith 4.1.2 and the client will not allow me to change to an alternative OS, plus my internal test server, I don't.
> As to the slowdown you have experienced, I don't understand why a
> security fix to samba would make any difference at all.
Nor do I, but it is a fact. I gave details in a message a few days ago and saw some confirmatory messages from others, as well as one or two who saw no change.
> Nevertheless, any information you can provide about problems with
> the system can only help us, you and other users.
If you are involved with disk intensive file processing you may notice a distinct problem with Update 3. The example I supplied earlier is to do with graphics file conversions.
On my test server I routinely carry out work for our own document scanning bureau business. One of the processes involves reading multipage G4 tiff files from the server disk to a workstation [Windows XP Pro] and converting them to Scansoft Paperport *.max files using the file import procedure of PaperPort itself, before writing them back to the server in another directory. Each conversion run involves a selection of 12-15 files varying from 60KB to 6MB in size and perhaps totalling 12MB. As each file is processed the importer displays a thermometer bar progress meter.
On 5.5, 5.6b7 and 5.6 unsupported release, this proceedure will hesitate and run slowly for the first file or perhaps the first two, and then each conversion for the rest of the day will run at high speed, the thermometer bar moving smoothly at a speed proportional to the size of the file being processed.
On Update 3 the process runs very slowly, with each page of the multipage file taking 3 or 4 seconds and the workstation processor having time to write a thumbnail of the partially converted file to the screen. This wading-through-treacle pace will persist for three or four files and then the rapid progress mentioned above will start and the batch is completed quickly.
With earlier releases, as I said above, the next batch will begin running at full speed and this will continue for the rest of the session, but with update 3, and to some extent with update 2, the dog-slow condition returns at the beginning of each batch. The net effect is to add hours to the processing of a large tranche of files.
The other symptom of the problem is the appearance, since update 2, of events at the server which can be distinctly heard as bursts of intensive disk activity, and during which all workstations stop dead if they happen to be communicating with the server at the time. There seems to be a relationship between mail activity on the server and this problem.
Let me further add a note about permission and file property difficulties with SME.
Certain Windows programs can not have their files stored on SME servers, and possibly not on any kind of Samba based SMB provider. Critically for me with a number of clients in the accountancy business, these include all of the Sage professional accounting packages, particularly Sage Taxation Suite [the product formerly known as Apex Taxation] and Sage Accounts Production. In that first case, the software runs once installed with its data on an SME server, but, as of Version 6 released this month, it cannot be updated. In the second case, the product registration process does not persist beyond the day on which the registration is carried out and, before the product can be used the next day, it has to be registered all over again.
The final situation of which I am aware is that Microsoft Access databases *cannot* be successfuly stored on SME servers. At some point corruption will occur as I have seen, now, on several occasions. This isn't the end of the world, because the MySQL set up you provide does a more than adequate job of substituting. Sadly however, some of the Sage products are Access runtime programs and get into difficulties. One in particular is the Practice Management package which a lot of accountants use to bill their time.
These, and a number of concerns about the commercial model used by Mitel, are the reasons why I will not use SME in client installations at this time.
> And if you do know of reliability problems with linux software RAID, please let us
> know details.
I don't, except for one situation: if one of your disks goes down you will suffer down time putting it right. They also give about a 2% loss of speed relative to a single disk and don't compare for performance to a decent SCSI system.
Ed Form