Log in

No account? Create an account
entries friends calendar profile My Website Previous Previous Next Next
Futzing with a USB storage thingeee - Mark Atwood
Futzing with a USB storage thingeee
I was given a box of MySQL PS swag. One of the items is a 256MB USB storage thingeee. I just tried mounting it for the first time today, it's got some interesting quirks.

  • It doesnt have a MBR or a partition table, instead just formatted like a floppy disk, with a msdos boot sector at the start. This is different from all the other storage thingees I own, which are all formatted like HDs, and have a partition table. This difference sometimes confused the hald automounter.
  • It has no MSDOS filesystem label. Thus it got mounted as "/media/disk". That I consider a weakness in the hald automounter. If there is no disklabel, there are lots of good things to fallback to. Maybe I should dig into hald and see how hard this would be to add and how welcomeing they would be to the patch.
    • MSDOS fs serialnumber: "A018-E668"
    • SCSI device serialnumber: "4CD98788"
    • USB device serialnumber: "4CD98788"
    • SCSI bus,channel,id,lun,vendor,model: "05000000 Generic Storage Alcor Flash Disk"
    • USB bus,port,dev,mfgr,prod: "040317 Generic Mass Storage"
  • And when I dump out the raw sector blocks, most of the them are just strings of "FF", but occationally there is a 32bit value at the beginning or end of a sector. Maybe the remains of the factory qualification tests?

I'm thinking of reformatting it, and then keeping my MySQL SSH key on it.

Tags: , , , ,
Current Location: Home, Capitol Hill, Seattle WA
Current Music: the dog chewing on it's toy

2 comments or Leave a comment
loganb From: loganb Date: November 16th, 2007 09:28 pm (UTC) (Link)
The SCSI and USB based identifiers would be sub-optimal as the drive would mount at a different location if I plugged it into a different port. Of course, mounting it as "disk" as suffers from that problem in the case that I plug in two of them in an arbitrary order.

NAND flash memory is cleared a block at a time which causes all bits in the block to switch high. Writing to flash consists of pulling select bits on a page (usually 1/16th or 1/32nd of a block) low. A page may be written to typically up to 3 times between erasure cycles. What you're likely seeing are erased blocks. After you've cycled data across the drive a couple of times, most of those blocks will likely contain "garbage" data that is waiting to get erased.
fallenpegasus From: fallenpegasus Date: November 16th, 2007 10:05 pm (UTC) (Link)
I understand that suboptimality. Thus taking that option should be tried only after one has tried and failed to mount the device by label, by fs id num, and then device hardware serial number.

If I wanted to be really complete, I would also populate the getattr fields of the mountpoint with all this kind of stuff, and also pass it to the desktop handler (Nautilus, etc), so that it would display on the mount icon, if it's not otherwise set.

And while I'm waving my hands and shooting off my mouth, if the device doesn't have a label or a fs id num, and it's being mounted read/write, I would have HAL compute and assign such, and write them to the device.

Probably for the label I would use a base-36 encoding of the current UNIX time for the label, and use the same alg that MSDOS FORMAT did for computing the fs id num.
2 comments or Leave a comment