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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
0 *H÷ 010 `He0 *H÷ $Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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?yes, enabling discard is pointless though (no USB storage supports it AFAIK). =20> 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=20 CPU) so it will be slow no matter what you do =20> 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...)?aligning logical blocks to erase blocks can give some performance but the only=20 way to make it really fast is not to use USB =20> Many thanks in advance, > Stephane > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html=2D-=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 Ê0Æ0® `DÖ0Ìó0 *H÷ 0Q1*0(U!QBS Class 3 Certificate Authority10U QBS Jan Kuban10 UPL0 110516100532Z 120516100532Z0¦10 *H÷ hka@qbs.com.pl10UHubert Kario10 U*Hubert10UKario10U QBS Jan KubaÅ10UWarszawa10Umazowieckie10 UPL0"0 *H÷ 0 ¶dÔ£?Bwú37æç§/U[ÝRZd1Ý£ò³å¯'¿ÓÑBDÒbRuyû$#üÍYq)2Þ´ðR¡7<íCC*]q¶P÷+Õ]FÄTÐæ«óÐßʾǤ,Lßa÷K\£ª¸j!FLe>°£1ïC_^×Òo¡ý8×Öí¥N£+ÉKjDÛÐìÄ} ÔM¸Hl÷Ï6-ñÒ'ÿrEnQ°¯² i8 Æ.)ÆÛæÔé|/Z"ÿd0Ä/7SÎéj¶k[ `÷ÝÁ$hKê,ÒÃçeèaø÷ݽ2EÇ×G£J0F0Q+E0C0A+05http://ca.qbs.com.pl:8080/ejbca/publicweb/status/ocsp0Ug¦"ÐÇ17\ã-K-Ö/Lä0Uÿ00U#0SγÕÜ¿B úµ¥õEDÛ,0ýUõ0ò0ï http://ca.qbs.com.pl:8080/ejbca/publicweb/webdist/certdist?cmd=crl&issuer=ou=QBS%20Class%203%20Certificate%20Authority,o=QBS%20Jan%20Kuban,c=PL¢U¤S0Q1*0(U!QBS Class 3 Certificate Authority10U QBS Jan Kuban10 UPL0Uÿ°0bU%[0Y+++ +7 +7 +7 +7 *H÷/0/U(0&hka@qbs.com.plwebmaster@qbs.com.pl0 *H÷ MÐ¥m¦%±gݣآ[9O«l-CCF-±¶ZÜÙůôgÖEYèz^¨qéÈ,"# âlîº~è?ì]Õ"Uyi{ ? - ªôbtÓêé²Ò.ïe½³ÞÁ©_UBÂHêÂ8©ì;Æsñ±ce½5åí7êÏw-Eðº¥G¾0îÍÖ``cï ¸àÎüéøêDr²ä£õX¯4y}þ,æwaÜHØÙ2[7PfS!ÇÌæõ=õîj˪ÝB-ûsRØ-TO·Ë¢mR¾¤5ǺC9¾Eò }Q9)K-â/öKcyphaB;s}á>£üßmñc>sdIº·#Ù1ãÇc{v,®íTñû6Nb;Ýý½üíaºDtYKýà| º¾Aô½Ü?nK¸céÅ6ØϾIêã?FXçÝAºö¸lU%º=Io¤ü«n-Ø v4¾)0újv Çbr0bù¨ïêýÝÚɾʪNÝ>Ø{ÄÍÏÄ,àóùY`¦N4~nÛÓZ-ìþl¬¿»LÅ:FxZré ®3ÓÂáä{100]0Q1*0(U!QBS Class 3 Certificate Authority10U QBS Jan Kuban10 UPL`DÖ0Ìó0 `He 0 *H÷ 1 *H÷ 0 *H÷ 1 110519190455Z0( *H÷ 100 `He0 *H÷ 0/ *H÷ 1" d]õM"ÒXWdÝõ´Í-é5¦·uv¼T°q 0 *H÷ 1êVºòé.y¼E1ØD8ÍóÕh~Hô>1ÚÄÍeoåÞ°QA±gô©á?¾<õHRu«¨*PÕoD#çc£cÎkës³¼3M?) ê/µ+¿z`I8Ùno)ïnСqYÑaQgòùdM&ýà~Çúì#J.úo I¤À6`óߣ#Á꾺L¿ùL4¾µUvÕiì_³ÎS4V«°¿ò¸W¼$x'ß8?(·/X¶ÖWÔN]v$y°Z¾%>Ñ"½Öqê PY4iåV^Î êák$Êyðá9DÐN§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±nÚß²)í æèw*jg¬±¨¶Ý¢j/êäz¹Þà2Þ¨èÚ&¢)ß¡«a¶Úþø®G«éh®æj:+v¨wèÙ¥
Sorry, loks like list mailer doesn''t like SMIME messages. On Thursday 19 of May 2011 21:04:54 Hubert Kario wrote:> On Wednesday 18 of May 2011 00:02:52 Stephane Chazelas wrote: > > 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). > > > 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 > > > 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...)? > > aligning logical blocks to erase blocks can give some performance but the > only way to make it really fast is not to use USB > > > Many thanks in advance, > > Stephane-- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2011-05-19 21:04:54 +0200, Hubert Kario:> On Wednesday 18 of May 2011 00:02:52 Stephane Chazelas wrote: > > 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). > > > 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 doThanks 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. [...]> 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. -- Stephane -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> [...] >> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2011-05-19 15:54:23 -0600, cwillu: [...]> Try with the "ssd_spread" mount option.[...] Thanks. I''ll try that.> > 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.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 -- Stephane -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 19, 2011 at 4:12 PM, Stephane Chazelas <stephane_chazelas@yahoo.fr> wrote:> 2011-05-19 15:54:23 -0600, cwillu: > [...] >> Try with the "ssd_spread" mount option. > [...] > > Thanks. I''ll try that. > >> > 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. > > 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/. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html