From: cwillu <cwillu@cwillu.com>
To: Stephane Chazelas <stephane_chazelas@yahoo.fr>
Cc: Hubert Kario <hka@qbs.com.pl>, linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: ssd option for USB flash drive?
Date: Thu, 19 May 2011 15:54:23 -0600 [thread overview]
Message-ID: <BANLkTinxt3N2_=STRiiJsOAYWEd2-yx_FA@mail.gmail.com> (raw)
In-Reply-To: <20110519214721.GA4209@yahoo.fr>
> [...]
>> aligning logical blocks to erase blocks can give some performance but the only
>> way to make it really fast is not to use USB
> [...]
>
> For something that fits in your pocket and is almost
> universally bootable, there are not so many other options.
An ssd drive in a USB enclosure is about the size of a cell phone,
just a thought.
> I tried changing the alignment on FAT32 and it didn't make
> any difference. Playing with /proc/sys/vm/block_dump, I could see
> chunks of 3, 4, 5 data sectors being written at once regardless
> of the cluster size being used anyway. Interestingly when a user
> process writes to /dev/sdx, block_dump shows 4k writes to
> /dev/sdx only regardless of the size of the user writes while if
> it goes via the filesystem I can see writes of up to 120k. Also,
> I've very little knowledge of what happens at layers below the
> block device (scsi interface, usb-storage, and the device
> controller itself, for instance, I see
> /sys/block/sdi/queue/rotational is 1 for that usb stick, why,
> what does that mean in terms of performance and scheduling of
> read-writes?)
Try with the "ssd_spread" mount option.
> I wonder now what credit to give to recommendations like in
> http://www.patriotmemory.com/forums/showthread.php?3696-HOWTO-Increase-write-speed-by-aligning-FAT32
> http://linux-howto-guide.blogspot.com/2009/10/increase-usb-flash-drive-write-speed.html
>
> Doing a apt-get upgrade on that stick takes hours when the same
> takes a few minutes on an internal drive.
Also, there's a package "libeatmydata" which will provide an
"eatmydata" command, which you can prefix your apt-get commands with.
This will disable the excessive sync calls that dpkg makes, and should
dramatically decrease the time for those sorts of things to finish.
Flash as found in thumb drives doesn't have much in the way of crash
guarantees anyway, so you're not really giving up much safety.
next prev parent reply other threads:[~2011-05-19 21:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-17 22:02 ssd option for USB flash drive? Stephane Chazelas
2011-05-19 19:04 ` Hubert Kario
2011-05-19 19:53 ` Hubert Kario
2011-05-19 21:47 ` Stephane Chazelas
2011-05-19 21:54 ` cwillu [this message]
2011-05-19 22:12 ` Stephane Chazelas
2011-05-19 22:19 ` cwillu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='BANLkTinxt3N2_=STRiiJsOAYWEd2-yx_FA@mail.gmail.com' \
--to=cwillu@cwillu.com \
--cc=hka@qbs.com.pl \
--cc=linux-btrfs@vger.kernel.org \
--cc=stephane_chazelas@yahoo.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox