Hi, I use SuSE 10 and when I try to copy or delete an 8 MB or higher file to my pen drive, it takes longer than the amout of time it takes in a win PC, specifically in KDE. What could be wrong? tommie -- ______________________________ msc. tomas alberto ramirez andujar sistemas de informaci'on y redes departamento de tecnologia educativa iplac - cel - la habana - cuba +537 274 14 79 - www.iplac.rimed.cu
tommie ramirez andujar wrote:
Hi,
I use SuSE 10 and when I try to copy or delete an 8 MB or higher file to my pen drive, it takes longer than the amout of time it takes in a win PC, specifically in KDE.
What could be wrong? tommie
It used to work quite well, until someone at SUSE decided to "fix" it, by mounting those drives with the sync option. There is a fix of questionable value or you can simply manually mount it, with sync not set.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-03-02 at 20:37 -0500, James Knott wrote:
It used to work quite well, until someone at SUSE decided to "fix" it, by mounting those drives with the sync option.
Actually, I agree with SuSE: mounting "sync" is the correct thing to do with automounted pluggable drives. The user could unplug the device before the kernel has even decided it's time to write to it. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEB6DwtTMYHG2NR9URAtceAJ9g4vGR3tJFk9Xx18ijMv/w+rpGngCfTVkl c8H8pQ0uNpAcK3OMj4xs5mA= =ptcj -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The Thursday 2006-03-02 at 20:37 -0500, James Knott wrote:
It used to work quite well, until someone at SUSE decided to "fix" it, by mounting those drives with the sync option.
Actually, I agree with SuSE: mounting "sync" is the correct thing to do with automounted pluggable drives.
The user could unplug the device before the kernel has even decided it's time to write to it.
If a drive takes an incredibly long time to write to, a user may just give up in frustration and unplug it anyway. If SUSE insists on using sync, they'd better find a way to make it usable. I have a 1 GB pen drive. I do not want to wait such a long time to write to it. Right now my choices are to manually mount it or plug it into my notebook, booted into Windows, and pull the file over the network.
On Thursday 02 March 2006 06:03 pm, James Knott wrote:
Carlos E. R. wrote:
The Thursday 2006-03-02 at 20:37 -0500, James Knott wrote:
It used to work quite well, until someone at SUSE decided to "fix" it, by mounting those drives with the sync option.
Actually, I agree with SuSE: mounting "sync" is the correct thing to do with automounted pluggable drives.
The user could unplug the device before the kernel has even decided it's time to write to it.
If a drive takes an incredibly long time to write to, a user may just give up in frustration and unplug it anyway. If SUSE insists on using sync, they'd better find a way to make it usable. I have a 1 GB pen drive. I do not want to wait such a long time to write to it.
I thouroughly agree. This is an oversight that probably shouldn't have happened. But then, I'd rather they focus on including DVD playback. I see more and more the Major Suppliers of Marketing Solutions are Making Sales pitches aimed at Multimedia Systems on our desktops with Mostly with a Single source of DRM content from one Major Software company.
Right now my choices are to manually mount it or plug it into my notebook, booted into Windows, and pull the file over the network.
Eewww! That blows. I really haven't had an issue since I installed the "fix" mentioned on bugzilla. Of course, I still cant' auto-connect to my WiFi network, but that's another story. -- kai - www.perfectreign.com www.livebeans.com - the new NetBeans community
kai wrote:
If a drive takes an incredibly long time to write to, a user may just give up in frustration and unplug it anyway. If SUSE insists on using sync, they'd better find a way to make it usable. I have a 1 GB pen drive. I do not want to wait such a long time to write to it.
I thouroughly agree. This is an oversight that probably shouldn't have happened.
But then, I'd rather they focus on including DVD playback. I see more and more the Major Suppliers of Marketing Solutions are Making Sales pitches aimed at Multimedia Systems on our desktops with Mostly with a Single source of DRM content from one Major Software company.
As I understand it, the issues are legal, not techincal.
On Thu, 2006-03-02 at 21:03 -0500, James Knott wrote:
Carlos E. R. wrote:
The Thursday 2006-03-02 at 20:37 -0500, James Knott wrote:
It used to work quite well, until someone at SUSE decided to "fix" it, by mounting those drives with the sync option.
Actually, I agree with SuSE: mounting "sync" is the correct thing to do with automounted pluggable drives.
The user could unplug the device before the kernel has even decided it's time to write to it.
If a drive takes an incredibly long time to write to, a user may just give up in frustration and unplug it anyway. If SUSE insists on using sync, they'd better find a way to make it usable. I have a 1 GB pen drive. I do not want to wait such a long time to write to it. Right now my choices are to manually mount it or plug it into my notebook, booted into Windows, and pull the file over the network.
I have the same frustration with the pen drives, we have four, and mp3 players, we have three.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-03-02 at 21:03 -0500, James Knott wrote:
Actually, I agree with SuSE: mounting "sync" is the correct thing to do with automounted pluggable drives.
The user could unplug the device before the kernel has even decided it's time to write to it.
If a drive takes an incredibly long time to write to, a user may just give up in frustration and unplug it anyway. If SUSE insists on using sync, they'd better find a way to make it usable. I have a 1 GB pen drive. I do not want to wait such a long time to write to it. Right now my choices are to manually mount it or plug it into my notebook, booted into Windows, and pull the file over the network.
I understand your frustration, but the proper "Linux way of things" is to manually mount things, IMO. The kernel can buffer the content that is going to be sent to a device, and actually wait a long time before writing it - several seconds is normal, but it could be way more. It is very possible for a user to unplug the device before writing is finished. However, when you issue the command "umount", this doesn't return till all writing has finished, and is really safe to remove the device. SuSE decision - if it is SuSE's - to use the option "sync" is the proper thing to do for automounted devices. If this makes the device very slow, the problem lies in the kernel developers field, not in SuSE's. Then, if you modify the scripts so that it doesn't use "sync", that's your decision and you know what it involves: waiting for a prudential time before unplugging. Or, simply mount manually. But SuSE can not make that assumption in your stead. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFECJe3tTMYHG2NR9URAlbgAJsGxG2moqXGKt3uOuHmT4MnsBE4ngCeMBMO c+PbkKPsKFnaYZxKnR78jck= =gn9i -----END PGP SIGNATURE-----
On Friday 03 March 2006 11:23 am, Carlos E. R. wrote:
The Thursday 2006-03-02 at 21:03 -0500, James Knott wrote:
Actually, I agree with SuSE: mounting "sync" is the correct thing to do with automounted pluggable drives.
The user could unplug the device before the kernel has even decided it's time to write to it.
If a drive takes an incredibly long time to write to, a user may just give up in frustration and unplug it anyway. If SUSE insists on using sync, they'd better find a way to make it usable. I have a 1 GB pen drive. I do not want to wait such a long time to write to it. Right now my choices are to manually mount it or plug it into my notebook, booted into Windows, and pull the file over the network.
I understand your frustration, but the proper "Linux way of things" is to manually mount things, IMO.
Ewww! Who would want to do that? <serious mode> I can imagine that - for the hardcore geeky type who still thinks of the CLI as a usable interface - this might be a good option. However, the rest of us want - no, expect - the drive to be available for writing and reading seconds after plugging it in.
The kernel can buffer the content that is going to be sent to a device, and actually wait a long time before writing it - several seconds is normal, but it could be way more. It is very possible for a user to unplug the device before writing is finished. However, when you issue the command "umount", this doesn't return till all writing has finished, and is really safe to remove the device.
SuSE decision - if it is SuSE's - to use the option "sync" is the proper thing to do for automounted devices. If this makes the device very slow, the problem lies in the kernel developers field, not in SuSE's.
Then, if you modify the scripts so that it doesn't use "sync", that's your decision and you know what it involves: waiting for a prudential time before unplugging. Or, simply mount manually.
Actually, it won't let you close the Konqueror window until it has stopped writing, so there's no issue, AFAIK. -- kai - www.perfectreign.com www.livebeans.com - the new NetBeans community
On Saturday 04 March 2006 04:53, kai wrote:
On Friday 03 March 2006 11:23 am, Carlos E. R. wrote:
The Thursday 2006-03-02 at 21:03 -0500, James Knott wrote:
Actually, I agree with SuSE: mounting "sync" is the correct thing to do with automounted pluggable drives.
The user could unplug the device before the kernel has even decided it's time to write to it.
If a drive takes an incredibly long time to write to, a user may just give up in frustration and unplug it anyway. If SUSE insists on using sync, they'd better find a way to make it usable. I have a 1 GB pen drive. I do not want to wait such a long time to write to it. Right now my choices are to manually mount it or plug it into my notebook, booted into Windows, and pull the file over the network.
I understand your frustration, but the proper "Linux way of things" is to manually mount things, IMO.
Ewww! Who would want to do that? <seroius mode> A Lot of us Actually
I can imagine that - for the hardcore geeky type who still thinks of the CLI as a usable interface - this might be a good option. The Best option The CLI still blows the crap outta the GUI and will continue to do so for the foreseable future However, the rest of us want - no, expect - the drive to be available for writing and reading seconds after plugging it in. WindBloZe this Aint
Actually, it won't let you close the Konqueror window until it has stopped writing, so there's no issue, AFAIK.
-- kai - www.perfectreign.com
www.livebeans.com - the new NetBeans community
-- The Labour party has changed there emblem from a rose to a condom as it more accuratley reflects the governments political stance. A condom allows for inflation halts production destroys the next gereration, protects a bunch of pricks, and givesyou a sense of security while you are actually bieng fucked from GSM
On Saturday 04 March 2006 04:16 am, Peter Nikolic wrote:
On Saturday 04 March 2006 04:53, kai wrote:
On Friday 03 March 2006 11:23 am, Carlos E. R. wrote:
The Thursday 2006-03-02 at 21:03 -0500, James Knott wrote:
Actually, I agree with SuSE: mounting "sync" is the correct thing to do with automounted pluggable drives.
The user could unplug the device before the kernel has even decided it's time to write to it.
If a drive takes an incredibly long time to write to, a user may just give up in frustration and unplug it anyway. If SUSE insists on using sync, they'd better find a way to make it usable. I have a 1 GB pen drive. I do not want to wait such a long time to write to it. Right now my choices are to manually mount it or plug it into my notebook, booted into Windows, and pull the file over the network.
I understand your frustration, but the proper "Linux way of things" is to manually mount things, IMO.
Ewww! Who would want to do that? <seroius mode>
A Lot of us Actually
Be my guest. Just don't force us to.
I can imagine that - for the hardcore geeky type who still thinks of the CLI as a usable interface - this might be a good option.
The Best option The CLI still blows the crap outta the GUI and will continue to do so for the foreseable future
Wholly disagree. Yes, I could run a series of commands - makeisofs, cdrecord, cdrdao - faster at any given time than running K3B, but reading the fscking incomprehensible MAN files and trying to figure out the litany of options would take far longer than simply opening the GUI and having it all done for me. Remember, I want to get things done, not tinker. If I wanted to tinker, I'd get myself a copy of slackware.
However, the rest of us want - no, expect - the drive to be available for writing and reading seconds after plugging it in.
WindBloZe this Aint
No, it isn't. It is a far superior product, which doesn't deserve this type of attitude. Just because Microsoft made a UI perform in a particular manner doesn't mean it is necessarily bad. -- kai - www.perfectreign.com www.livebeans.com - the new NetBeans community
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-03-04 at 08:48 -0800, kai wrote:
I understand your frustration, but the proper "Linux way of things" is to manually mount things, IMO.
Ewww! Who would want to do that? <seroius mode>
A Lot of us Actually
Be my guest.
Just don't force us to.
We don't... but there are consequences you have to suffer :-P - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFECjdbtTMYHG2NR9URAtayAJ4sec5vIP/2JCrYhEqBtdYDAbTY9ACeMha7 RAv8jAKsvd/MyQXVDZYuXwc= =9h92 -----END PGP SIGNATURE-----
kai wrote:
I can imagine that - for the hardcore geeky type who still thinks of the CLI as a usable interface - this might be a good option.
However, the rest of us want - no, expect - the drive to be available for writing and reading seconds after plugging it in.
I might add, writable at a decent speed. If you can go for dinner and it's still writing when you come back, that is not acceptable. That is, unfortunately, the default situation with SUSE. It worked well previously and they broke it.
Actually, it won't let you close the Konqueror window until it has stopped writing, so there's no issue, AFAIK.
That certainly beats Windows, where you've got those flying documents that don't let you do anything else. It reminds me of demonstrating OS/2 to people a few years ago. They were amazed that with OS/2, you could actually do something else, while formatting a floppy! ;-) With Windows, your computer was essentially locked up, during formatting. With OS/2, you started the format, and went back to whatever you were doing. You'd then have to check to see if the formatting was finished, because it had such an insignificant impact on performance, that you never noticed it had completed.
On Saturday 04 March 2006 05:00 am, James Knott wrote:
kai wrote:
I can imagine that - for the hardcore geeky type who still thinks of the CLI as a usable interface - this might be a good option.
However, the rest of us want - no, expect - the drive to be available for writing and reading seconds after plugging it in.
I might add, writable at a decent speed. If you can go for dinner and it's still writing when you come back, that is not acceptable. That is, unfortunately, the default situation with SUSE. It worked well previously and they broke it.
Agreed! My mom - on 9.2 - uses her USB cards all the time. She's got two cameras each with SD cards. When I built her system I gave her an all-in-one USB reader/floppy. She - like I - expects to put the card in the slot, have Konq come up and display the files, and then simply copy/xfer and pull it out when done. We also expect it to work at a reasonable speed.
Actually, it won't let you close the Konqueror window until it has stopped writing, so there's no issue, AFAIK.
That certainly beats Windows, where you've got those flying documents that don't let you do anything else. It reminds me of demonstrating OS/2 to people a few years ago. They were amazed that with OS/2, you could actually do something else, while formatting a floppy! ;-)
Heh - I remember back in '94, while working at my first programming job - we had two spare DX/40 IBM MCA computers, which were identical. Since we were already programming for OS/2 (2.1) and had been testing with Warp, we decided to put the new Windows 4.0 (a.k.a. Windows 95) to a speed test. We setup both systems with the base install for each OS (DOS/Win95 and OS/2 Warp) and then created a list of tasks. We opened CLI windows for running compile jobs, setup batch jobs for performing disk actions and put floppies in each drive. We then let each system go to work. The Windows 95 machine took about 30 minutes to perform all the tasks. The OS/2 machine did the same in less than one minute. Unfortunately, OS/2 had many other shortcomings - driver availability, Ugly and non-intuitive UI and an elitist attitude - which doomed it from the start. I supported it for a few more years on IVR systems until I moved on and relegated myself to using NT 4.0. I had tried Linux several times during this period, but it wasn't until about a year ago that it became mature enough - IMO - to be used on a daily basis. I still have a set of OS/2 Warp floppies, by the way. (This along with a copy of OS/2 1.3.)
With Windows, your computer was essentially locked up, during formatting.
Still, is pretty much an issue. Unfortunately the folks in redmond have yet (as of XP) to figure out how to write a pre-emptive multi-tasking kernel. I don't know if linux is pre-emptive or cooperative, but it certianly functions better than NT/XP.
With OS/2, you started the format, and went back to whatever you were doing. You'd then have to check to see if the formatting was finished, because it had such an insignificant impact on performance, that you never noticed it had completed.
-- kai - www.perfectreign.com www.livebeans.com - the new NetBeans community
kai wrote:
I still have a set of OS/2 Warp floppies, by the way. (This along with a copy of OS/2 1.3.)
I still have a few versions here and have one computer running Warp 4
With Windows, your computer was essentially locked up, during formatting.
Still, is pretty much an issue. Unfortunately the folks in redmond have yet (as of XP) to figure out how to write a pre-emptive multi-tasking kernel. I don't know if linux is pre-emptive or cooperative, but it certianly functions better than NT/XP.
With OS/2, you started the format, and went back to whatever you were doing. You'd then have to check to see if the formatting was finished, because it had such an insignificant impact on performance, that you never noticed it had completed.
It's pre-emptive MT. Even Windows 3.1 has it, for the DOS sessions, as DOS doesn't know about cooperative MT. However, Windows apps in 3.1 and 3.1 apps, running in W95, W98 etc., are also cooperative MT. I believe Macs, prior to the BSD kernel were to. OS/2 only used cooperative MT within WinOS2 sessions. Separate WinOS2 sessions were pre-emptive.
On Saturday 04 March 2006 19:52, James Knott wrote:
It's pre-emptive MT. Even Windows 3.1 has it, for the DOS sessions, as DOS doesn't know about cooperative MT.
er, no, windows 3.1 was a shell running on top of DOS, so it had nothing of the sort. And of course DOS had nothing even close to multitasking of any sort.
Anders Johansson wrote:
On Saturday 04 March 2006 19:52, James Knott wrote:
It's pre-emptive MT. Even Windows 3.1 has it, for the DOS sessions, as DOS doesn't know about cooperative MT.
er, no, windows 3.1 was a shell running on top of DOS, so it had nothing of the sort. And of course DOS had nothing even close to multitasking of any sort.
Windows 3.1 apps relied on cooperative multitask and were built to deal with it. When you had mulitple DOS sessions running they had no mechanism for cooperative MT, so the OS had to stop one session to allow another to run. As we all know from experience, it didn't work very well, but it was still pre-emptive, in that the app had absolutely no control over it, unlike apps written for cooperative MT.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-03-04 at 14:08 -0500, James Knott wrote:
Windows 3.1 apps relied on cooperative multitask and were built to deal with it. When you had mulitple DOS sessions running they had no mechanism for cooperative MT, so the OS had to stop one session to allow another to run. As we all know from experience, it didn't work very well, but it was still pre-emptive, in that the app had absolutely no control over it, unlike apps written for cooperative MT.
That's correct. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFECjavtTMYHG2NR9URAhmiAJ48PknVpznvGpADyn/DvVpqVLIukwCfRkeT Lhky3OXAZJ3ZadHMdxI5drA= =xeGU -----END PGP SIGNATURE-----
On Sat, 2006-03-04 at 19:55 +0100, Anders Johansson wrote:
On Saturday 04 March 2006 19:52, James Knott wrote:
It's pre-emptive MT. Even Windows 3.1 has it, for the DOS sessions, as DOS doesn't know about cooperative MT.
er, no, windows 3.1 was a shell running on top of DOS, so it had nothing of the sort. And of course DOS had nothing even close to multitasking of any sort.
I thought that DR-Dos towards the end of it's life did.
Mike McMullin wrote:
On Sat, 2006-03-04 at 19:55 +0100, Anders Johansson wrote:
It's pre-emptive MT. Even Windows 3.1 has it, for the DOS sessions, as DOS doesn't know about cooperative MT. er, no, windows 3.1 was a shell running on top of DOS, so it had nothing of
On Saturday 04 March 2006 19:52, James Knott wrote: the sort. And of course DOS had nothing even close to multitasking of any sort.
I thought that DR-Dos towards the end of it's life did.
I don't know about DR-DOS, but there was crude multitasking for DOS, with TSRs and 3rd party utilities.
On Fri, 2006-03-03 at 20:53 -0800, kai wrote:
On Friday 03 March 2006 11:23 am, Carlos E. R. wrote:
{snip}
The kernel can buffer the content that is going to be sent to a device, and actually wait a long time before writing it - several seconds is normal, but it could be way more. It is very possible for a user to unplug the device before writing is finished. However, when you issue the command "umount", this doesn't return till all writing has finished, and is really safe to remove the device. SuSE decision - if it is SuSE's - to use the option "sync" is the proper thing to do for automounted devices. If this makes the device very slow, the problem lies in the kernel developers field, not in SuSE's.
Then, if you modify the scripts so that it doesn't use "sync", that's your decision and you know what it involves: waiting for a prudential time before unplugging. Or, simply mount manually.
Actually, it won't let you close the Konqueror window until it has stopped writing, so there's no issue, AFAIK.
Isn't that thee big question? Knowing that we have data integrity?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-03-03 at 20:53 -0800, kai wrote:
Actually, it won't let you close the Konqueror window until it has stopped writing, so there's no issue, AFAIK.
And... how does konkeror knows that the kernel has finished writing? <:-) Because konkeror might have finished, but the kernel can keep writing even for a minute or two more (nosync, you know). Provided we use konkeror, there are many other things that could be writing there. OOo, for instance. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFECbECtTMYHG2NR9URAtuYAJ9QG/aT/1L3gD0k7jaSp9i2RknHXgCdHSfX ZgL1X6aDWFFhGkGg+gYzLp0= =Glfm -----END PGP SIGNATURE-----
On Saturday 04 March 2006 07:23 am, Carlos E. R. wrote:
The Friday 2006-03-03 at 20:53 -0800, kai wrote:
Actually, it won't let you close the Konqueror window until it has stopped writing, so there's no issue, AFAIK.
And... how does konkeror knows that the kernel has finished writing? <:-)
Because konkeror might have finished, but the kernel can keep writing even for a minute or two more (nosync, you know).
Don't know, don't really care. It seems to work. HOW it works is not my issue. -- kai - www.perfectreign.com www.livebeans.com - the new NetBeans community
Carlos E. R. wrote:
The Friday 2006-03-03 at 20:53 -0800, kai wrote:
Actually, it won't let you close the Konqueror window until it has stopped writing, so there's no issue, AFAIK.
And... how does konkeror knows that the kernel has finished writing? <:-)
Because konkeror might have finished, but the kernel can keep writing even for a minute or two more (nosync, you know).
Provided we use konkeror, there are many other things that could be writing there. OOo, for instance.
So, in order to prevent corruption, we make the device unusable? These devices usually have lights that flash. When the flashing has stopped for a few seconds, it's done.
On Saturday 04 March 2006 19:42, James Knott wrote:
So, in order to prevent corruption, we make the device unusable? These devices usually have lights that flash. When the flashing has stopped for a few seconds, it's done.
Asynchronous I/O isn't quite as simple as that. Even in that model of usability windows you have to wait for the OS to pop up a window saying "it is now safe to remove your device" or some such. The only way to know is to unmount the device if it's mounted async
Anders Johansson wrote:
On Saturday 04 March 2006 19:42, James Knott wrote:
So, in order to prevent corruption, we make the device unusable? These devices usually have lights that flash. When the flashing has stopped for a few seconds, it's done.
Asynchronous I/O isn't quite as simple as that. Even in that model of usability windows you have to wait for the OS to pop up a window saying "it is now safe to remove your device" or some such. The only way to know is to unmount the device if it's mounted async
There's got to be something better than crippling the device. Someone else mentioned the window won't close, until the transfer has completed. If the desktop is checking to make sure there are no open files, then that should be good enough. According to the instructions that came with my SanDisk 1 GB drive, Windows XP users can wait for the light to stop flashing and other verisons have to click on that icon to allow safe removal. Even something like that, is far preferrable to waiting hours for writing to complete.
On Saturday 04 March 2006 20:04, James Knott wrote:
According to the instructions that came with my SanDisk 1 GB drive, Windows XP users can wait for the light to stop flashing and other verisons have to click on that icon to allow safe removal. Even something like that, is far preferrable to waiting hours for writing to complete.
Then follow the instructions in the knowledgebase to disable automounting for the USB storage devices, and mount them manually. This can even be done from within KDE to give you a GUI point'n'click interface. You'll get the async speeds of writing, and you umount manually to make sure it's in a safe state Watching the light implies that the flushing of the buffers is continuous, which is something at least I wouldn't trust to be true. Just because the system isn't flushing to the device at the moment doesn't necessarily mean there's nothing left to be flushed
Guys, I think we're missing the point here. Mounted sync or no sync, writing to a USB flash drive in SUSE 10.0 takes forever. Without sync it just *appears* faster but you still wait the same amount of time for it to finish up. According to the Konq. copy progress thingy, writing to my USB flash drive happens at 30-40kb/s. This is a USB2 device on a USB2 controller. This is slower than even USB 1.1 used to be. In SUSE 9.3 writing to a USB flash drive, again, sync or no sync, was a lot quicker. The weird thing is, if I put a normal IDE drive in an external USB enclosure, and plug that in, I can write at 26mb/s while it is mounted sync. So why is it different for flash drives? What broke between 9.3 and 10.0? Hans
Hans du Plooy wrote:
Guys,
I think we're missing the point here. Mounted sync or no sync, writing to a USB flash drive in SUSE 10.0 takes forever. Without sync it just *appears* faster but you still wait the same amount of time for it to finish up. According to the Konq. copy progress thingy, writing to my USB flash drive happens at 30-40kb/s. This is a USB2 device on a USB2 controller. This is slower than even USB 1.1 used to be.
In SUSE 9.3 writing to a USB flash drive, again, sync or no sync, was a lot quicker.
The weird thing is, if I put a normal IDE drive in an external USB enclosure, and plug that in, I can write at 26mb/s while it is mounted sync.
So why is it different for flash drives? What broke between 9.3 and 10.0?
I have found there's in immense difference betweeing sync and no sync. Without sync, it's usable. With sync, it's not. Last night, I was getting 5 - 6 MB/s. that's 40 - 48 Mb/s on USB 2. With sync, I was generally getting under 20 KB/s and a lot of "stalled" messages. Use the mount command, to ensure it's really mounted without sync.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-03-04 at 21:32 +0200, Hans du Plooy wrote:
In SUSE 9.3 writing to a USB flash drive, again, sync or no sync, was a lot quicker.
The weird thing is, if I put a normal IDE drive in an external USB enclosure, and plug that in, I can write at 26mb/s while it is mounted sync.
So why is it different for flash drives? What broke between 9.3 and 10.0?
If that is so, and is measurable, then there probably is a kernel problem somewhere. In my experience, nosync is faster simply because the kernel can delay and optimize the order of writing to a device. It is very effective on external zip drives, for instance. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFECjTLtTMYHG2NR9URAhN+AJ94a2HWh2ffXnvb2a/p4XUe59j78QCdGhoi UGwnj1x4NELlcNJ60uuAoUs= =1AVT -----END PGP SIGNATURE-----
Hans du Plooy wrote:
Guys,
I think we're missing the point here. Mounted sync or no sync, writing to a USB flash drive in SUSE 10.0 takes forever. Without sync it just *appears* faster but you still wait the same amount of time for it to finish up. According to the Konq. copy progress thingy, writing to my USB flash drive happens at 30-40kb/s. This is a USB2 device on a USB2 controller. This is slower than even USB 1.1 used to be.
In SUSE 9.3 writing to a USB flash drive, again, sync or no sync, was a lot quicker.
The weird thing is, if I put a normal IDE drive in an external USB enclosure, and plug that in, I can write at 26mb/s while it is mounted sync.
So why is it different for flash drives? What broke between 9.3 and 10.0?
Hans
I mount my USB pend rive asynchronously, Copy the file, and umount it.. Wait until it umounts, then pull it off the drive. I get about 100 KBytes per sec on a USB 1.1 version of my "pen drive". I usually move about 20 to 60 mega bytes per second. This only takes me a couple of minutes. -- Joseph Loo jloo@acm.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-03-05 at 07:50 -0800, Joseph Loo wrote:
I mount my USB pend rive asynchronously, Copy the file, and umount it.. Wait until it umounts, then pull it off the drive. I get about 100 KBytes per sec on a USB 1.1 version of my "pen drive". I usually move about 20 to 60 mega bytes per second. This only takes me a couple of minutes.
The maximun transfer speed for usb 1 is 12MBit/s, ie, 1.5 Mbyte/s, not counting overheads. If you get 20..60 Mb/s, it is the buffer speed you are measuring, not the real device speed. Also, internally, the flash memory can attain a maximun speed of 100Mbit/s, ie, 12Mb/s - it is not possible to go higher than that. (according to wikipedia, http://en.wikipedia.org/wiki/USB_Flash_Drive#Strengths_and_weaknesses) - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEC49vtTMYHG2NR9URAmjeAJ0cAosFD5SvQfFZjYLFoYWg4ZVa+wCdEVJO YOdGPxbJdoUHj4BnFe405Qo= =H3YP -----END PGP SIGNATURE-----
participants (9)
-
Anders Johansson -
Carlos E. R. -
Hans du Plooy -
James Knott -
Joseph Loo -
kai -
Mike McMullin -
Peter Nikolic -
tommie ramirez andujar