Tag Info

New answers tagged

3

USB 2.0 or 3.0 is a hardware specification and has little to do with the OS. There's no way to downgrade (or upgrade) an specific USB version. What you can do is plugging your device in a 2.0 hub. USB 3.0 is totally backwards compatible with 2.0 and 1.1 devices, but some glichs can appear in the kernel implementation of the specification, in such cases is ...


0

One solution I find for this problem is to use udev. Edit /etc/udev/rules.d/99-automount.rules with your favorite editor and add those lines: # --sync to allow removal without corruption # exclude sda since its the rootfs ACTION=="add",KERNEL=="sd[bcd]*", RUN+="/usr/bin/pmount --sync --noatime --umask 000 %k" ACTION=="remove", KERNEL=="sd[bcd]*", ...


0

The biggest concern is probably memory wear which causes flash memory to have much fewer writes than magnetic media before failing. Of course, standard hard drives fail also, so just ensure that you have backups suitable to the needs of whatever you are doing with the machine.


-1

Now that I look again, I realized you said this was a usb key ( flash drive ) not a hard drive. Flash memory can only be erased in large blocks, and individual sectors can not be written without erasing them ( and the whole block they are in ) first. Since software expects to be able to write wherever it wants on the disk at any time, the disk has ...


-1

This happens due to the optimization of writing Sparse files in filesystem. When you do dd if=/dev/zero to raw device, the zero blocks are actually written to disk. However when you write them to a file, the filesystem ignores writing the data and saves just the metadata. This results in very few blocks being written to disk. The file can be seen as a big ...


3

UPDATE So, I really didn't think I would be researching NTFS this morning, but, thanks mostly to @AndrewMedico's comments below, I learned something. The truth is file streams are weird, and they confuse me, but apparently it gets deeper. Behaving in a way very like NTFS file streams, Transactional NTFS commits file changes to some alternate cache until ...


0

Try using hdparm instead to benchmark a drives performance with and without using any caching: $ sudo hdparm -tT /dev/sda1 /dev/sda1: Timing cached reads: 6314 MB in 2.00 seconds = 3157.61 MB/sec Timing buffered disk reads: 244 MB in 3.04 seconds = 80.26 MB/sec


0

Your measurement results can be explained with the kernel architecture. Using filesystem access will unlease the full potential of the kernel with all buffers and optimizations that it can do. Especially the buffers will speed up your benchmark (b/c the kernel is 100% a_A_syncronous). dd on a device file does not use any/much of this.


0

If you're far enough along to reach a terminal prompt that's more than far enough to concatenate as many images as you could desire. All you need to do from there is: zcat <init.image | { cd / ; cpio -i \ --make-directories \ # #Create leading directories where needed --preserve-modification-time \ # ...


0

Also, if you want windows to be able to see more than just the first unhidden windows-compatible volume on a "removable" USB, then install the "Hitachi Microdrive Filter" driver using windows Device Manager for that specific USB after it has been plugged in & enumerated with the windows default driver. That PC will then see all the windows-compatible ...


0

I would write zeroes to sdb3 in linux: dd if=/dev/zero of=/dev/sdb3 bs=32k Then format it as FAT32. Make sure to LABEL the volume whenever you format or reformat it. You should really label all your volumes whenever multibooting or anything else! Then mount the full-size Kali ISO (not the mini-ISO) (or put the disk in the CDROM drive if already burned ...



Top 50 recent answers are included