it's deleting about 100 per second.  Is this normal?  It's only one data drive in the array and no parity as of yet.

 

Running 5.0 rc3.

 

EDIT:  Running Mac OS X Snow Leopard 10.6.8 as client via AFP.

do you get any better on your SL system itself?

 

That's a lot of files, and chances are they're tiny - meaning there's a lot of file system overhead reconfiguring all those index points as the files are 'deleted'

 

I've never tried to delete that many files from UnRAID before, but even if I did, all my files are many MB or GB in size, so I know it'll take a while anyway.

 

The Movie Jukebox database I use with my Dune player is made of up 28K really small files and 17K folders (I think the whole thing is about 3 GB.  The few times I have just outright deleted it whether stored on unRAID or locally on a windows computer it is really slow.  It's always measured in files per second instead of MB/S.

 

it's deleting about 100 per second.  Is this normal?  It's only one data drive in the array and no parity as of yet.

 

Running 5.0 rc3.

 

EDIT:  Running Mac OS X Snow Leopard 10.6.8 as client via AFP.

[/quote

 

Seems to me 100 deletes per sec via AFP is fairly decent.

Not at all familiar with Mac, but this is very much in line with everything I have seen on Windows, and Linux machines with HHD's.

Now SSD's is a whole different ball game, they delete 5-10 times quicker.

Not at all familiar with Mac, but this is very much in line with everything I have seen on Windows, and Linux machines with HHD's.

Now SSD's is a whole different ball game, they delete 5-10 times quicker.

 

Not true.

 

I, too, noticed how slow the file deletes were the other day, but as I'm new to unRAID, I figured it was a trade off for using a network drive.  I am still running unRAID beta 12a with no parity drive enabled yet.

 

To prove my point, I added an older 250GB IDE drive to my Windows PC. The primary Windows drive is a 256GB SSD. I created some test data to delete (MAME files), of a sufficient quantity so that Windows would display the number of items being deleted per second (about 100,000 ten kilobyte files). I copied them to the SSD and to a single, non-parity protected, previously empty drive in unRAID.

 

I noted what was a best guess average files deleted per second.

 

_Really old_ 250GB IDE drive:

Started at 7,000 files/second, averaged about 3,800 files/second

 

New 256GB SSD:

Started at 5,500 files/second, average about 3,500 files/second

 

1.5TB unRAID drive:

Started at 370 files/second, average very steady 296-300 files/second

 

Now my question is, will unRAID will the same or slower once parity is enabled? Is this speed a beta issue or just standard for unRAID? (my guess is that it's normal).

 

In unRAID's defense, it is for media storage, not thousands of tiny files.

 

 

...Donovan

I think you'll find it's not a function of using unRAID, but that deleting files on network attached storage is going to be much slower than on a local machine.  Windows, for example, will cache write operations to drives, so that deletions happen in cached areas of a drive and the physical media catches up sometime later.  That would be considered a little dangerous from the point of view of data integrity.  What happens if the machine crashes while there are a bunch of modified disk sectors in cache?  When you delete files on a networked server, the deletions are done one at a time and with the data disks and parity being updated for each deletion - a much safer strategy, but one which takes a lot longer.

Now my question is, will unRAID will the same or slower once parity is enabled?

Slower.  Limited by rotational speed of the two disks involved.

Is this speed a beta issue or just standard for unRAID? (my guess is that it's normal).

Nothing to do with beta versions.  Everything to do with file-system-type involved (reiserfs is a"balanced tree" internally.  deletions of files result in the tree being re-balanced.) and parity protection (need to both read and write the sectors involved in the deletion).

In unRAID's defense, it is for media storage, not thousands of tiny files.

Exactly..  the file-system type was chosen for MANY reasons, and the possibly longer time to delete many thousands of small files was not one of them.

 

From my recollection, the file-system type was chosen for

  Ability to be re-sized dynamically

  No need to specify number of "inodes"

  Journaling... (able to recover from partial writes in the event of a power failure)

  Efficiency when use with large files typically found in media storage.

 

Joe L.