Any well known working USB 3.0 Stick as Cache device

[redline]

Because the access to directory with thousands of small fils is very slow i want to assist with a cache device.
All Sata ports are in use and so i looked for a USB 3.0 stick. The plan was to use him for L2arc secondary cache only on metadata

I found a Transcend Jetflash 780 16GB device with 140 Mb/read and 40 Mb/write.
I cannot get it to work. During boot time i see some mass storage / scsi error meassages.
Trying to format either with ufs or selecting as ZFS Pool device didn't worked. I was able to create a virtual cache device. But trying to add him as cache to my pool
didn't worked. At least it will be recognized with correct size and brand and model.
Maybe it's just "incompatible".

That's why i ask also if there is maybe a USB 3.0 stick known which works out of the box with Freebsd / N4F.

The Usb bridge itself should be okay. I had a few weeks a 4TB external Hitachit Touro running on this port.
I also tried this stick at a slow USB 2.0 port. Same results. It can't get it to work.
I tried if "Gpart destroy" could do the trick but no luck.

[raulfg3]

Use a USB3 as cache device is not a good idea, google a bit to find simmilar ideas:

http://forums.freenas.org/archive/index.php/t-7189.html

http://hardforum.com/showthread.php?t=1687724

[redline]

I asked which USB 3.0 stick is well known to work generally under Freebsd and N4F.
See it more in the sense of what the kernel can recognize during boottime. (hardware compatibility)

Offcourse i read this stuff you linked me too, before.

But i did't want this stick as a Zil device. Only as a L2ARC and this on top , broken down only to metadata !!! ( NOT CACHE ALL which is default)
The directory structures i would like to search or scan very often didn't change much and so the metadata is most of the time still the same.
I only want to accelerate this searches over this directory trees. So there are rare, seldom writes on the USB stick.

Even after reading all the stuff about this theme over the last days i don't see the point why it should not work.

The only thing is that this particulary stick is maybe to new and not handled on hardware level side or the brand "Transcend" has maybe
some silly software on it (which i didn't ordered) .... I had in the past a few other sticks with nice gimicks like "my own security area".
I didn't need it, but it was already there .... and it was even harder to get rid of this stuff. No partition tool was able to kill it.
I found finally a software from the brand to "repair" this stick and so i got rid of the unwanted stufff.

That's why i ask for brand, , modell of a USB 3.0 stick which works fine out of the box under Freebsd 9.x

[BeNooL]

I'm also using USB to act a ZFS metadata-only cache device and can confirm the added value in terms of speed for directory navigation or file searches.

I also happen to have a USB3 Transcend Jetflash 16Gb that I'd somehow had intented for that ZFS cache usage. The machine it is intended for however only has USB2. What I did (with other keys) is install NAS4Free on the key and specify some of the remainder as swap. After install, i add this swap partition as ZFS cache.

[redline]

Thanx for this info. I'm unfortunately not good enough at the Freebsd command line to realize such a splitted System and Cache stick.

I tested yesterday with another smaller and slower USB 3.0 stick from Verbatim. At least setup and even partitioning with gpart was now possible.
Yes, It speed up things but i didn't got the turbo effect i hoped for. Maybe i'm hunting something impossible.

In daily windows world i often use Totalcommander and scan large directory trees with thousands of files. Locally on the NTFS filesystem and combined
with the caching mechanism windows offers it's a breeeze. Doing the same on the NAS is a nightmare.
But after i activated the cache device and setting up the dataset value "secondardycache= metadata" there was an increase but not as assumed.
I logged then into the NAS over putty and made some tests with the local running find commando..
The speed was pretty good. So it seems that the bottleneck is the network itself (samba, CIFS)

The typical samba screws over the WebGui like buffers, Async IO , Large Sent etc etc have no influence here.
Are there maybe some options to optimize this specific behaviour or is it something i just have to live with.

[redline]

Once again ...
I have tested several USB sticks now. I also installed once a SSD on a free E-Sata port. I cannot measure really any performance difference.
From my windows client, a second or third access is faster. But this seems only be related to the windows internal caching.

Wit the USB sticks i have on top another problem. Shutting down the engine or a reboot over the Webgui didn't work anymore as long as
such a "cache" is added to the pool(s) ... You can see on the cli that the last messgage is that the UBS controllers are shutted down.
Here the NAS hangs then forever. I have to switch it off over the Power Button.
After a reboot the cache is correctly attached to the pool again and seems to work.

I tried to prepare the stick either as MBR or GPT partitions and also tried UFS or freebsd-zfs slices.
I don't know if and which filesystem is needed on the cache device.
Anyway, It makes no difference .. Shutting down or rebooting isn't possible with the attached stick.
It hangs after USB device shutdown. (this didn't happened with a SSD !)

Is there maybe a solution known ?

[BeNooL]

I reported the same issue with USB cache device here => viewtopic.php?p=11697#p11697

I'll have to try with newly released 621 build.

[redline]

I had a look at this topic. Seems no one answers in any way. I don't see a hint there why we could assume that in 621 build it would , could be fixed.
But okay, i'm not alone then with this problem.
Did you measured , feeled a big difference with caching metadata only. I'm not impressed til now.

I watched via gstat ... While scanning a big directory with 20000 small files i see that main disk ada4 is accessed very often.
And on the corresponding cache which is in my case da4pq1 i see only frequently write accesses.
So scanning the same directory on and on i can see only very slowly that something is handled over the cache.
Because ARC is an adaptive caching maybe there no chance to force all metadata into it.
On the slow disk i see 3.5 til 7ms and on the USB stick i see 0.5ms til 1.2ms access time.
So , if there would be all metadata cached it might be a little bit quicker.

Are there any other parameters which can be adjusted in this topic ?
I started with setting the secondarycache = metadata on the datasets. Later i tried the whole pool not knowing if there is a
parent -> child relationship

[BeNooL]

Not fixed in newer builds

viewtopic.php?p=15954#p15954