1

On a limbo-type fake USB or SD card, all sectors starting from a specific position on the drive are unavailable (zeroes only or ones only or unreadable sector response).

A flash drive might indicate itself as 256GB but actually has 16 GB only. Anything written beyond the 16GB threshold goes into a digital black hole (hence limbo). When trying to access that data, one of these things might happen:

  • The device returns blank sector with 00000000 (0x00) bytes only.
  • The device returns sector with 11111111 (0xFF) bytes only.
  • The device signalizes the computer that the sector is damaged.
  • The device freezes up for an indefinite timespan and never returns the read request.
  • The device returns random data (very rare type)

On the rogue flash drive I own, the first one is the case. It returns 00 00 00 00 … in all 512 bytes of sectors in all sectors inside the limbo area, which is beyond the actual data capacity.

Using mkfs or gparted on a fake USB (for testing purposes) for creating filesystems does freeze up for an indefinite time.

Both Windows and Android successfully format the SD card to the full alleged capacity needing less than half a minute. This can only be possible when not touching any file system footers that are beyond the actual capacity. Only by modifying headers.
GParted and mkfs freeze up indefinetly (until removing the drive from the PC) and leave a file system indicated with the unknown type in GParted.

How can I format a rogue flash drive in GParted to the full alleged capacity while only writing file system headers?

That would make GParted not touch the limbo area that causes the indefinite freeze (not to confuse with the fourth listed type of sector returns on rogue drives. It is the reaction of GParted).

What I am trying to achieve:

  • Testing how Linux reacts to swapon onto a fake flash drive. Because this is too trivial for StackExchange, I decided to try it out myself.
  • Testing different file systems (ext2, ext3, ext4, FAT16, FAT32, exFAT, f2fs, xfs, zfs, ntfs) on an Android mobile phone: I would like to try recording video using an Android mobile phone, beyond the actual capacity, to see how it reacts.

closed as unclear what you're asking by Rui F Ribeiro, sourcejedi, schily, Isaac, jimmij Nov 6 '18 at 9:12

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I tried mkfs.exfat. That gets stuck on “Flushing . . .” indefinitely. – neverMind9 Nov 5 '18 at 3:14
  • 3
    are you trying to sell the bad flash drives as good? – jsotola Nov 5 '18 at 3:46
  • 2
    What are you trying to achieve in the end? I'm asking because this could be an XY question. If I had such a drive I would want to partition it, so that no partition was inside the "limbo area". Then mkfs on the partition would have no reason to touch the "limbo area". If you want to do something else, then I do not understand why, so I am probably missing important details that would affect your question! – sourcejedi Nov 5 '18 at 10:24
  • @jsotola No. I want to experiment at home. If I wanted to sell them as good, I could just format them using Windows. I deliberately bought the fake flash drive. (It is a Micro SD card, no USB stick.) – neverMind9 Nov 5 '18 at 15:55
  • @sourcejedi I will edit the question right away. – neverMind9 Nov 5 '18 at 16:00
1

I sort of doubt this is going to work. But there is a robust method that should do what you are asking for. If this doesn't work, there is no option you could pass to mkfs to do anything better.

  1. Create a (sparse) file on your main filesystem which is the same size as the device. E.g. use truncate --reference=/dev/sdX disk.img
  2. Partition the file (I assume you want this - if you don't then skip it and use /dev/loopN instead of /dev/loopNp1). You can run fdisk disk.img, or dd if=/dev/sdX of=disk.img conv=notrunc bs=1M count=1 to copy whatever partition is on the device.
  3. losetup -f disk.img - this will create a loop device and print its name.
  4. mkfs.FOO /dev/loopNp1 - create the filesystem
  5. dd if=/dev/loopN of=/dev/sdX bs=1k count=16M conv=sparse - copy the first 15G (16*1024*1024*1024) of the disk image into the device. You can adjust this as needed. conv=sparse will skip writing blocks which are all zeros.
  • This is a heavy workaround, but still thank you. It would be good if mkfs had a switch that solved this problem. Android successfully formats those SD cards so I wonder why Linux would not. – neverMind9 Nov 6 '18 at 11:25
  • 1
    @neverMind9 if you want to know, I think you need to look at the operation in mkfs that freezes. You can use strace to look at whether write() or fsync() calls are stalling for a long time, and you can use blktrace to watch the exact IO requests that are sent to the device and see if they are taking a long time to complete. If the device is stalling completely, I think you should also see timeouts in dmesg. For this purpose I would be slightly wary of only using mkfs.exfat, since I don't think Linux exfat support is very mature, I would want to cross-check with mkfs.ext4. – sourcejedi Nov 6 '18 at 11:48
  • 1
    @neverMind9 In short, you shouldn't expect mkfs to behave well if the device takes a long time to complete operations. If you want to blame mkfs, you need to rule out that the device is playing up. There is no real-world reason for mkfs to want to behave well on devices that fake their capacity, so you can only complain if it seems to be hanging when you are certain there is no reason for it to hang. – sourcejedi Nov 6 '18 at 11:50
  • 1
    @neverMind9 I suspect is the answer boils down to "your device is evil", with a side-order of "your device was tested against Windows, and Linux happens to do something different". There could be many possible differences! Since we know the device is evil, there is not a real-world reason for Linux developers to carefully match Windows behaviour in this particular case. (In some other cases, Linux aims for "bug-for-bug" comparability because the hardware was only tested for Windows). – sourcejedi Nov 6 '18 at 11:59
  • 1
    Better attempt at being short: it is not "good" for mkfs to add code etc to handle something if literally only one person wants it :-). – sourcejedi Nov 6 '18 at 12:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.