ssd option for USB flash drive?
Hiya,
I've not found much detail on what the "ssd" btrfs mount option did. Would it make sense to enable it to a fs on a USB flash drive?
I'm using btrfs (over LVM) on a Live Linux USB stick to benefit from btrfs's compression and am trying to improve the performance.
Would anybody have any recommendation on how to improve performance there? Like what would be the best way to enable/increase writeback buffer or any way to make sure writes are delayed and asynchronous? Would disabling read-ahead help? (at which level would it be done?). Any other tip (like disabling atime, aligning blocks/extents, figure out erase block sizes if relevant...)?
Many thanks in advance,
Stephane
Sorry, loks like list mailer doesn't like SMIME messages.
Quoted 10 lines · On Thursday 19 of May 2011 21:04:54 Hubert Kario wrote:
Quoted 5 lines · On Wednesday 18 of May 2011 00:02:52 Stephane Chazelas wrote:
Hiya,
=20
I've not found much detail on what the "ssd" btrfs mount option did. Would it make sense to enable it to a fs on a USB flash drive?=20
yes, enabling discard is pointless though (no USB storage supports it AFAIK).
=20
Quoted 7 lines
Quoted 3 lines
I'm using btrfs (over LVM) on a Live Linux USB stick to benefit from btrfs's compression and am trying to improve the performance.
=20
ssd mode won't improve performance by much (if any).
=20
You need to remember that USB2.0 is limited to about 20-30MiB/s (depe=
nding
Quoted 11 lines
on CPU) so it will be slow no matter what you do
=20Quoted 7 lines
Would anybody have any recommendation on how to improve performance there? Like what would be the best way to enable/increase writeback buffer or any way to make sure writes are delayed and asynchronous? Would disabling read-ahead help? (at which level would it be done?). Any other tip (like disabling atime, aligning blocks/extents, figure out erase block sizes if relevant...)?
=20
aligning logical blocks to erase blocks can give some performance but=
the
Quoted 4 lines
only way to make it really fast is not to use USB
=20Quoted 2 lines
Many thanks in advance,
Stephane
--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=F3w 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
2011-05-19 21:04:54 +0200, Hubert Kario:
Quoted 9 lines · On Wednesday 18 of May 2011 00:02:52 Stephane Chazelas wrote:
Quoted 5 lines
Hiya,
I've not found much detail on what the "ssd" btrfs mount option did. Would it make sense to enable it to a fs on a USB flash drive?
yes, enabling discard is pointless though (no USB storage supports it AFAIK).
Quoted 8 lines
Quoted 3 lines
I'm using btrfs (over LVM) on a Live Linux USB stick to benefit from btrfs's compression and am trying to improve the performance.
ssd mode won't improve performance by much (if any).
You need to remember that USB2.0 is limited to about 20-30MiB/s (depending on CPU) so it will be slow no matter what you do
Thanks Hubert for the feedback.
Well, for hard drives over USB, I can get to 40MiB/s read and write easily. Here, I believe the bottle neck is the flash memory. With that particular USB flash drive Corsair Voyager GT 16GB, I can get 25MiB/s sequential read and 17MiB/s sequential write, but that falls down to about 3-5MiB/s random write.
[...]
Quoted 2 lines
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.
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?)
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.
If I boot a kvm virtual machine on that USB stick with a disk cache mode of "unsafe", that is writes are hardly every flushed to underlying storage, then that becomes lightning fast (at the expense of possibly losing data in case of host failure, but I'm not too worried about that), and flushing writes to device upon VM shutdown only takes a couple of minutes.
So I figured that if I could make sure writing to the flash device is asynchronous (and reads priviledged), that would help.
There's probably some solutions with aufs or some fuse solutions, but I thought there might be some solution in btrfs or some standard core layers usually underneath it.
Signature · 1 line
Stephane
Quoted 7 lines
[...]
Quoted 2 lines
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.
Quoted 5 lines
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_dumpshows 4k writes to
Quoted 8 lines
/dev/sdxonly 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/rotationalis 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.
Quoted 6 lines
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.htmlDoing 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.
2011-05-19 15:54:23 -0600, cwillu:
[...]
Quoted 1 line
Try with the "
ssd_spread" mount option.
[...]
Thanks. I'll try that.
Quoted 7 lines
Quoted 6 lines
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.htmlDoing a apt-get upgrade on that stick takes hours when the same takes a few minutes on an internal drive.
Quoted 6 lines
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.
Thanks. That's very useful indeed.
Note that if you use that on aptitude/apg-get that means that the daemons started/restarted in the process will be affected, but it could be all the better in my case.
Now, with that eatmydata, I'm thinking of trying qemu-nbd -c /dev/nbd0 /dev/mapper/original-device with that and have the rootfs mounted on that /dev/nbd0.
That eatmydata could be a work around to the problem I was mentionning at
https://lists.ubuntu.com/archives/ubuntu-server-bugs/2010-June/037846.html
Signature · 1 line
Stephane
Quoted 21 lines · Stephane Chazelas
2011-05-19 15:54:23 -0600, cwillu:[...]
Quoted 1 line
Try with the "
ssd_spread" mount option.[...]
Thanks. I'll try that.
Quoted 7 lines
Quoted 6 lines
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.htmlDoing a apt-get upgrade on that stick takes hours when the same takes a few minutes on an internal drive.
Quoted 6 lines
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.
Quoted 5 lines
Thanks. That's very useful indeed.
Note that if you use that on aptitude/apg-get that means that the daemons started/restarted in the process will be affected, but it could be all the better in my case.
Heh, that's a thought I hadn't actually considered :p
That shouldn't affect any services that are managed by message passing, and so really should be limited to those services from /etc/init.d/ that don't restart themselves (i.e., where the restart command is implemented by stop + start rather than telling the already running process to re-execute), or newly installed services that again are managed via /etc/init.d/.