pmrphs2002
06-05-2003, 08:14 PM
For something to chew on, i just deleted a folder with 4.3 GB worth of data at an average speed of 9.2 KB/S . I dont know how that compares to windows, but there it is.
Click to See Complete Forum and Search --> : Linux Speed In Moving Files
sharth
06-05-2003, 08:22 PM
well, in windows, it probably would take longer since it has to send it to the recycle bin and then sent to deletion.
it all depends on hard-drive speed though.
it all depends on hard-drive speed though.
glussier
06-05-2003, 09:16 PM
Originally posted by sharth
well, in windows, it probably would take longer since it has to send it to the recycle bin and then sent to deletion.
it all depends on hard-drive speed though.
When you delete a file in window, the file doesn't move, it is renamed, and a pointer in the fat table is changed.
well, in windows, it probably would take longer since it has to send it to the recycle bin and then sent to deletion.
it all depends on hard-drive speed though.
When you delete a file in window, the file doesn't move, it is renamed, and a pointer in the fat table is changed.
Hayl
06-05-2003, 09:30 PM
Originally posted by pmrphs2002
For something to chew on, i just deleted a folder with 4.3 GB worth of data at an average speed of 9.2 KB/S . I dont know how that compares to windows, but there it is.
what hdparm settings is that with ?
For something to chew on, i just deleted a folder with 4.3 GB worth of data at an average speed of 9.2 KB/S . I dont know how that compares to windows, but there it is.
what hdparm settings is that with ?
sharth
06-05-2003, 09:36 PM
Originally posted by glussier
When you delete a file in window, the file doesn't move, it is renamed, and a pointer in the fat table is changed. o. coolies :) hehe.
When you delete a file in window, the file doesn't move, it is renamed, and a pointer in the fat table is changed. o. coolies :) hehe.
JesseJames
06-05-2003, 09:44 PM
It doesnt even delete the file, it removes reference to it which iis why the files can be recovered.
There are utilities which do delete files in windows such as eraser (which i use). I just erased the temp diectory and the report it produced is shown below:
Statistics:
Erased area = 2440 kB
Cluster tips = 376 kB
Data written = 85400 kB
Write time = 64.09 s
Write speed = 1332 kB/s
I have just remembered that it actually works by overwriting the files :P
There are utilities which do delete files in windows such as eraser (which i use). I just erased the temp diectory and the report it produced is shown below:
Statistics:
Erased area = 2440 kB
Cluster tips = 376 kB
Data written = 85400 kB
Write time = 64.09 s
Write speed = 1332 kB/s
I have just remembered that it actually works by overwriting the files :P
hop-frog
06-05-2003, 11:00 PM
Originally posted by pmrphs2002
at an average speed of 9.2 KB/S
Where do you get that figure from? I tried man mv and it doesn't show up any option to display the speed.
at an average speed of 9.2 KB/S
Where do you get that figure from? I tried man mv and it doesn't show up any option to display the speed.
Strogian
06-06-2003, 08:44 AM
I'm thinking (4.3GB)/(time) would do it. :) I didn't realize that linux actually deleted files when you rm'ed them, though. I always figured it would just update directory entries.
Stween
06-06-2003, 08:51 AM
Originally posted by Strogian
I'm thinking (4.3GB)/(time) would do it. :) I didn't realize that linux actually deleted files when you rm'ed them, though. I always figured it would just update directory entries.
Linux doesn't actually remove the contents of a file when you delete it. I'd figure it just removes the inode that points to it ... that would explain why it is possible to recover deleted files.
It also makes sense from a filesystem perspective: why physically remove the data when you can simply mark the space as 'not in use'?
I'm thinking (4.3GB)/(time) would do it. :) I didn't realize that linux actually deleted files when you rm'ed them, though. I always figured it would just update directory entries.
Linux doesn't actually remove the contents of a file when you delete it. I'd figure it just removes the inode that points to it ... that would explain why it is possible to recover deleted files.
It also makes sense from a filesystem perspective: why physically remove the data when you can simply mark the space as 'not in use'?
Stween
06-06-2003, 08:56 AM
Originally posted by pmrphs2002
For something to chew on, i just deleted a folder with 4.3 GB worth of data at an average speed of 9.2 KB/S . I dont know how that compares to windows, but there it is.
The only time I'd think you'd see real slowdown like that would be either if the drive was under pressure anyway (lots of things trying to access different things at once), or if you were moving files across different drives/partitions in which case the whole file will have to be duplicated in its new location rather than just manipulating references to its location.
Although the subject is moving and the post is about deleting. So which is it? :)
For something to chew on, i just deleted a folder with 4.3 GB worth of data at an average speed of 9.2 KB/S . I dont know how that compares to windows, but there it is.
The only time I'd think you'd see real slowdown like that would be either if the drive was under pressure anyway (lots of things trying to access different things at once), or if you were moving files across different drives/partitions in which case the whole file will have to be duplicated in its new location rather than just manipulating references to its location.
Although the subject is moving and the post is about deleting. So which is it? :)
pmrphs2002
06-06-2003, 02:39 PM
Well ive noticed my error to begin with- It isn't sposed to read "kb/s" rather it should say "mb/s" lolol ..... big difference, huh?
And I gathered that number from the "moving...." window that I got when I moved it to the trash bin. It took it some time, so i noted the speed.
The post says delete cuz thats what I did. The text says move because it had to move to the trash folder before it could be removed (had to make sure there weren't important files in there :P)
And I gathered that number from the "moving...." window that I got when I moved it to the trash bin. It took it some time, so i noted the speed.
The post says delete cuz thats what I did. The text says move because it had to move to the trash folder before it could be removed (had to make sure there weren't important files in there :P)
JesseJames
06-06-2003, 04:06 PM
So this thread has basically lost all meaning for existing :confused:
Nuada Storm
06-06-2003, 04:06 PM
Good thing you clarified that. At 9.2 kb/s that is pretty pathetic.. Only a little faster than a 56K modem.
My primary drive moves files at 49.27 MB/Sec and my secondary drive moves files at 21.50 MB/Sec.
You can test this with hdparm using the command:
hdparm -t /dev/hda
Just substitute the device you want to test. If your drive isn't fast enough for you, then make sure that DMA is turned on for them if it is supported. For example before DMA was turned on, both of my drives were around 7 MB/Sec. There is a help file in the Just Linux library that tells you how to do this if you need the steps.
http://www.justlinux.com/nhf/Hardware/Hard_Drive_Speed_Tweak_for_Linux.html
My primary drive moves files at 49.27 MB/Sec and my secondary drive moves files at 21.50 MB/Sec.
You can test this with hdparm using the command:
hdparm -t /dev/hda
Just substitute the device you want to test. If your drive isn't fast enough for you, then make sure that DMA is turned on for them if it is supported. For example before DMA was turned on, both of my drives were around 7 MB/Sec. There is a help file in the Just Linux library that tells you how to do this if you need the steps.
http://www.justlinux.com/nhf/Hardware/Hard_Drive_Speed_Tweak_for_Linux.html
sploo22
06-06-2003, 04:33 PM
The speed all depends on the number of inodes (or files) to delete more than it does on the total size. This means that the speed would be considerably slower for a bunch of small files than for a dozen 400MB ones. It's not a fair comparison, people!
zdude255
06-06-2003, 05:04 PM
There is a way to physically overwrite the data on linux at the prompt without any special tools.
type:
shred files
Quite a well named command, even expensive forensic software cannot recover data from shred.
type:
shred files
Quite a well named command, even expensive forensic software cannot recover data from shred.
hop-frog
06-06-2003, 05:16 PM
I thought that shred doesn't work on journaled filesystems. Does that include ext3?
JohnT
06-06-2003, 06:25 PM
CAUTION: Note that shred relies on a very important assumption: that
the filesystem overwrites data in place. This is the traditional way
to do things, but many modern filesystem designs do not satisfy this
assumption. The following are examples of filesystems on which shred
is not effective:
* log-structured or journaled filesystems, such as those supplied with
AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)
the filesystem overwrites data in place. This is the traditional way
to do things, but many modern filesystem designs do not satisfy this
assumption. The following are examples of filesystems on which shred
is not effective:
* log-structured or journaled filesystems, such as those supplied with
AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)
raz0rblade
06-07-2003, 01:00 AM
My main box's hd does a 46mb/s with dma and 32bit on. Server is quite sad, only 8.75mb/s with 32bit and dma on. Any ideas on how speed up the server drive ? its a 7200rpm 20gb.
hop-frog
06-07-2003, 01:10 AM
I guess I have an older version of shred. The manpage dropped part about ext3:
CAUTION: Note that shred relies on a very important
assumption: that the filesystem overwrites data in place.
This is the traditional way to do things, but many modern
filesystem designs do not satisfy this assumption. The
following are examples of filesystems on which shred is
not effective:
* log-structured or journaled filesystems, such as those
supplied with
AIX and Solaris (and JFS, ReiserFS, XFS, etc.)
That's version 4.1.
CAUTION: Note that shred relies on a very important
assumption: that the filesystem overwrites data in place.
This is the traditional way to do things, but many modern
filesystem designs do not satisfy this assumption. The
following are examples of filesystems on which shred is
not effective:
* log-structured or journaled filesystems, such as those
supplied with
AIX and Solaris (and JFS, ReiserFS, XFS, etc.)
That's version 4.1.
Nuada Storm
06-07-2003, 01:20 AM
Originally posted by raz0rblade
My main box's hd does a 46mb/s with dma and 32bit on. Server is quite sad, only 8.75mb/s with 32bit and dma on. Any ideas on how speed up the server drive ? its a 7200rpm 20gb.
Make sure it is using its onboard cache and that the CD device is not on the same IDE channel.
My main box's hd does a 46mb/s with dma and 32bit on. Server is quite sad, only 8.75mb/s with 32bit and dma on. Any ideas on how speed up the server drive ? its a 7200rpm 20gb.
Make sure it is using its onboard cache and that the CD device is not on the same IDE channel.
raz0rblade
06-12-2003, 04:26 PM
How do i check onboard cache ? and no its on its own ide channel. Another test i did was the buffer-cache test and my main box scored 325mb/s whereas my server on has 17mb/s :confused: why so much differance?
justlinux.com
Copyright Internet.com Inc. All Rights Reserved.
Copyright Internet.com Inc. All Rights Reserved.