Hi,
On Fri, Jun 22, 2012 at 01:51:06PM +0000, Arnd Bergmann wrote:
On Monday 18 June 2012, Andreas Mohr wrote:
./flashbench -a /dev/sdb2 --blocksize=1024 align 8589934592 pre 371µs on 736µs post 370µs diff 365µs align 4294967296 pre 371µs on 739µs post 370µs diff 368µs align 2147483648 pre 370µs on 737µs post 371µs diff 366µs align 1073741824 pre 370µs on 740µs post 371µs diff 370µs align 536870912 pre 371µs on 740µs post 369µs diff 370µs align 268435456 pre 371µs on 752µs post 371µs diff 381µs align 134217728 pre 371µs on 739µs post 370µs diff 368µs align 67108864 pre 370µs on 738µs post 369µs diff 368µs align 33554432 pre 389µs on 741µs post 370µs diff 361µs align 16777216 pre 387µs on 737µs post 370µs diff 359µs align 8388608 pre 370µs on 738µs post 370µs diff 368µs align 4194304 pre 371µs on 736µs post 371µs diff 365µs align 2097152 pre 384µs on 736µs post 370µs diff 359µs align 1048576 pre 389µs on 736µs post 371µs diff 356µs align 524288 pre 370µs on 734µs post 370µs diff 364µs align 262144 pre 371µs on 735µs post 370µs diff 364µs align 131072 pre 384µs on 734µs post 369µs diff 358µs align 65536 pre 404µs on 737µs post 371µs diff 349µs align 32768 pre 401µs on 743µs post 369µs diff 358µs align 16384 pre 405µs on 485µs post 370µs diff 97.1µs align 8192 pre 383µs on 439µs post 371µs diff 61.5µs align 4096 pre 372µs on 415µs post 370µs diff 44.2µs align 2048 pre 404µs on 425µs post 371µs diff 37.1µs
So, this appears to indicate that the erase block size of Transcend TS32GSSD18M-M is 32kB.
Actually, 32KB would be the "superpage" size, which is a very different convept from the erase block size. The data you posted does not hint at the actual erase block size, but for a 32GB drive, it should be something around 8MB.
Argh, so it's time to re-write my newly installed system then, to use a "heuristically guessed" most suitable erase block size ;-P
I couldn't gather this complication from the docs at the time that I was analyzing this, so maybe docs don't explain this clearly enough yet? Or possibly the dumbness factor played a role here...
BTW, currently having a hard time getting my JMF601 to read out SMART, despite the docs claiming that it has it... (seems to be a general issue for many SCSI command submissions, e.g. SAT pass-through and the JMicron-specific ones, so there's still hope that something is to be tweaked on the Linux usb-storage side). Getting the usual invalidDCB (invalid field) sense code, so either this means (since it's the common "error" reply) that these commands are indeed not implemented, or it means that we do have a parameter issue somewhere.
Thanks,
Andreas Mohr