Re: proper newfs options for SSD disk
El día Sunday, June 17, 2012 a las 09:16:12PM -0600, Warren Block escribió: On Sat, 16 Jun 2012, Matthias Apitz wrote: OK, but I wanted to have most of the space of the 4 GB SSD encrypted with geli(8); so I should make there some slice containing /boot (unencrypted) and a second slice which later will contain my HOME and encrypted; wrong? That's correct: http://forums.freebsd.org/showthread.php?t=29652 Thanks for the pointers and the comments from you and Wojciech; I'm attaching below what I have planned as the exactly procedure now and would thank in advance for any comments; one remaining question is, how could I attache the geli(8) crypted file system during boot (via rc.conf) but using a passphrase which should be asked and typed in on boot? is this somehow possible? Thanks matthias $Id:$ current disk layout of EeePC: Filesystem SizeUsed Avail Capacity Mounted on /dev/ada0s1a3.7G568M3.1G15%/ /dev/ada1s1a 14G8.7G5.8G60%/usr/local future disk layout. /dev/ada0p1freebsd-boot /dev/ada0p2freebsd-ufs /boot 256 Mbyte /dev/ada0p3freebsd-ufs /private 3.5 GByte (geli encrypted) /dev/ada1p1freebsd-boot /dev/ada1p2freebsd-ufs /14.0 GByte (/ /usr /var ... all in one file system and unencrypted) commands: # gpart destroy -F ada0 # gpart create -s gpt ada0 # gpart add -t freebsd-boot -s 512k ada0 # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0 # gpart add -t freebsd-ufs -b 1m -s 256m ada0 # gpart add -t freebsd-ufs ada0 # gpart destroy -F ada1 # gpart create -s gpt ada1 # gpart add -t freebsd-boot -s 512k ada1 # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada1 # gpart add -t freebsd-ufs -b 1m ada1 this allows as well at the beginning to boot the system from ada1 (must be done manually from BIOS); later we will copy over /boot from ada1p2 to ada0p2 (see below); create on ada0 the future /boot and /privae file systems and on ada1 the future / root file system; and mount the last as /mnt # newfs /dev/ada0p2 # newfs /dev/ada0p3 # newfs /dev/ada1p2 # mount /dev/ada1p2 /mnt start the mouse daemon (only for cutpaste: # /etc/rc.d/moused onestart install the system (user land and kernel) from /usr/src to /mnt: # cd /usr/src # make installworld DESTDIR=/mnt # make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t # make distrib-dirs DESTDIR=/mnt # make distribution DESTDIR=/mnt create the future /etc/fstab to mount / as root fs: # echo /dev/ada1p2 / ufs rw 1 1 /mnt/etc/fstab configure some basic services in future /etc/rc.conf: # cat EOF /mnt/etc/rc.conf tmpmfs=YES tmpsize=128m wlans_ath0=wlan0 ifconfig_wlan0=WPA DHCP ifconfig_bge0=DHCP ifconfig_em0=DHCP hostname=aurora.Sisis.de sshd_enable=YES moused_enable=YES keymap=german.iso EOF create at least one unpriv user to be able to SSH into the new system later: # chroot /mnt /usr/sbin/adduser unmount the new / and reboot: # umount /mnt # reboot after reboot system should now come up from ada1 and we copy over the /boot to ada0p2 # mount /dev/ada0p2 /mnt # cp -Rp /boot /mnt # echo 'geom_eli_load=YES' /mnt/boot/loader.conf # echo 'vfs.root.mountfrom=ufs:ada1p2' /mnt/boot/loader.conf # umount /mnt # reboot should now boot by itself from ada0 and mount the tootfs from ada1p2; later we will use /dev/ada0p3 for the geli(8) encrypted file system and we will mount this as /private; my $HOME should be /private/home -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
future disk layout. /dev/ada0p1freebsd-boot /dev/ada0p2freebsd-ufs /boot 256 Mbyte /dev/ada0p3freebsd-ufs /private 3.5 GByte (geli encrypted) over 200 MB wasted for /boot. what do you want to but there? except this it is all right. /dev/ada1p1freebsd-boot /dev/ada1p2freebsd-ufs /14.0 GByte (/ /usr /var ... all in one file system and unencrypted) nonsense here. why partitions AT ALL? just /dev/ada1 - /, no partitions commands: # gpart destroy -F ada0 # gpart create -s gpt ada0 # gpart add -t freebsd-boot -s 512k ada0 # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0 # gpart add -t freebsd-ufs -b 1m -s 256m ada0 # gpart add -t freebsd-ufs ada0 i cannot help here as i am not really gpart user. i use bsdlabel everywhere for now. # newfs /dev/ada0p2 # newfs /dev/ada0p3 don't waste space, read newfs manual and add good options. on flash disks don't fear to use smallest (4KB) block size and smallest (512) fragment size. on any disk don't overallocate inodes as newfs do. You know how many files you have so i can't help you. newfs -i 16384 means over 1% locked space, on hard disks i usually use -i 65536 and it still result in most inodes unused. on small flash disks 16384 or 32768 is usually fine but YOU know how much files you store. on private system do not fear -m 0, even more on flash media where fragmentation doesn't hurt. and you definitely forgot -U option. REALLY - read out newfs manual carefully and make optimal filesystem layout every time. newfs defaults are certainly non optimal, but universal and mostly safe. # newfs /dev/ada1p2 # mount /dev/ada1p2 /mnt start the mouse daemon (only for cutpaste: # /etc/rc.d/moused onestart # echo /dev/ada1p2 / ufs rw 1 1 /mnt/etc/fstab rw,noatime always worth using, definitely on flash disks. the rest is quite complex for me. i would rather back up all your existing filesystem to something external, make new partitioning and restore. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On Tue, 19 Jun 2012, Matthias Apitz wrote: El día Sunday, June 17, 2012 a las 09:16:12PM -0600, Warren Block escribió: On Sat, 16 Jun 2012, Matthias Apitz wrote: OK, but I wanted to have most of the space of the 4 GB SSD encrypted with geli(8); so I should make there some slice containing /boot (unencrypted) and a second slice which later will contain my HOME and encrypted; wrong? That's correct: http://forums.freebsd.org/showthread.php?t=29652 Thanks for the pointers and the comments from you and Wojciech; I'm attaching below what I have planned as the exactly procedure now and would thank in advance for any comments; one remaining question is, how could I attache the geli(8) crypted file system during boot (via rc.conf) but using a passphrase which should be asked and typed in on boot? is this somehow possible? When set up like that link, it does ask for the passphrase on startup.___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
OK, but I wanted to have most of the space of the 4 GB SSD encrypted with geli(8); so I should make there some slice containing /boot (unencrypted) and a second slice which later will contain my HOME and encrypted; wrong? right. but do not forget bootloader requires things to be in /boot directory on boot partition so do it that way 20MB /b partition (a) rest - geli encrypted / partition (d) on / partition make link /boot - /b/boot put /boot things in /b/boot well done custom kernel should fit in 10MB /b partition including boot loader. and you can gzip /boot/kernel/kernel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On Sat, 16 Jun 2012, Matthias Apitz wrote: OK, but I wanted to have most of the space of the 4 GB SSD encrypted with geli(8); so I should make there some slice containing /boot (unencrypted) and a second slice which later will contain my HOME and encrypted; wrong? That's correct: http://forums.freebsd.org/showthread.php?t=29652 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
El día Wednesday, May 30, 2012 a las 07:44:37PM +0200, Wojciech Puchar escribió: from; one has to go (by pressing ESC) to the boot menu to pick it up as current boot device; any idea how this could be changed? boot from 4GB. just put /boot here and add vfs.root.mountfrom=ufs:XXX where XXX is your root filesystem device name with /dev/ stripped do not forget to bsdlabel -B your.4GB.SSD WARNING: you must have proper disklabel with a: partition containing UFS with /boot. But you may have a partition equal to whole disk a: 117231408 04.2BSD0 0 0 c: 117231408 0unused0 0 # raw part, don't edit and it is absolutely OK, UFS do not overwrite first few sectors as it is reserved for it. And PLEASE DO NOT make this stupid MSDOS style slices. It is not just unneeded but introduces mess and only mess. just have /dev/ad0a not /dev/ad0s1a OK, but I wanted to have most of the space of the 4 GB SSD encrypted with geli(8); so I should make there some slice containing /boot (unencrypted) and a second slice which later will contain my HOME and encrypted; wrong? matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
And PLEASE DO NOT make this stupid MSDOS style slices. It is not just unneeded but introduces mess and only mess. just have /dev/ad0a not /dev/ad0s1a What FreeBSD devs have to say about this? ;) OK, but I wanted to have most of the space of the 4 GB SSD encrypted with geli(8); so I should make there some slice containing /boot (unencrypted) and a second slice which later will contain my HOME and encrypted; wrong? matthias -- You can encrypt ANY provider. Put HOME on i.e; 'h' bsd label and encrypt it via geli. Or encrypt whole SSD and have /boot on USB stick or optical media, or ... Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On Jun 16, 2012 8:26 PM, rank1see...@gmail.com wrote: And PLEASE DO NOT make this stupid MSDOS style slices. It is not just unneeded but introduces mess and only mess. just have /dev/ad0a not /dev/ad0s1a What FreeBSD devs have to say about this? ;) I say we have GPT this decade :) Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
... # geli attach /dev/md1 Enter passphrase: # dd if=/dev/md1.eli of=/dev/null bs=128k count=4k 536868864 bytes transferred in 35.093015 secs (15298454 bytes/sec) # dd if=/dev/zero of=/dev/md1.eli bs=128k count=4k 536868864 bytes transferred in 38.044995 secs (14111419 bytes/sec) # geli detach /dev/md1 # mdconfig -d -u 1 As you can see the EeePC with it's Intel Celeron CPU of only 900 MHz is even faster then the Acer with Atom CPU; yes this is normal. Intel Atom have low IPC, but high IPJ (instruction per joule, still low compared to ARM). Yet - if you have hyperthreading it is actually not bad in IPC too with 2 threads. I generally think intel atom is great x86 processor as you simply do not need more power for PERSONAL computer. BTW: On the EeePC I run 10-CURRENT, KDE 3.5.10 and never encounter performance issues while reading, writing etc. right. It is normal. Even KDE is not that really that CPU bound, but still useless. Concerning your hint installing the systen on the second SSD of around 16 GByte (marketing GBytes :-)), the BIOS by itself is unable to boot right. 16 billion bytes. A simple marketing trick to cheat you for 7.6% from; one has to go (by pressing ESC) to the boot menu to pick it up as current boot device; any idea how this could be changed? boot from 4GB. just put /boot here and add vfs.root.mountfrom=ufs:XXX where XXX is your root filesystem device name with /dev/ stripped do not forget to bsdlabel -B your.4GB.SSD WARNING: you must have proper disklabel with a: partition containing UFS with /boot. But you may have a partition equal to whole disk a: 117231408 04.2BSD0 0 0 c: 117231408 0unused0 0 # raw part, don't edit and it is absolutely OK, UFS do not overwrite first few sectors as it is reserved for it. And PLEASE DO NOT make this stupid MSDOS style slices. It is not just unneeded but introduces mess and only mess. just have /dev/ad0a not /dev/ad0s1a ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
El día Wednesday, May 30, 2012 a las 07:44:37PM +0200, Wojciech Puchar escribió: Concerning your hint installing the systen on the second SSD of around 16 GByte (marketing GBytes :-)), the BIOS by itself is unable to boot right. 16 billion bytes. A simple marketing trick to cheat you for 7.6% I think, it's only 7.3% $ bc (16*1024*1024*1024-160)/160*100 7.300 but it's just to cheat you; and nobody cares about 1179869184 bytes, more then 1 billion of bytes :-( matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
Concerning your hint installing the systen on the second SSD of around 16 GByte (marketing GBytes :-)), the BIOS by itself is unable to boot right. 16 billion bytes. A simple marketing trick to cheat you for 7.6% I think, it's only 7.3% $ bc (16*1024*1024*1024-160)/160*100 7.300 thanks. but it's just to cheat you; and nobody cares about 1179869184 bytes, more then 1 billion of bytes :-( i do. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
El día Saturday, May 26, 2012 a las 04:01:54PM +0200, Wojciech Puchar escribió: Why? Your laptop have most probably slow CPU and it will make everything too slow if you make everything encrypted. I'd suggest some experiments - create a largish RAMdisk with and without GELI and see how the performance compares (this will be a lot faster than converting your SSD as well as saving a full-SSD erase/write cycle). right. DO TESTs. mdconfig -a -t swap -s512m -u 0 dd if=/dev/zero of=/dev/md0 bs=128k count=4k dd if=/dev/md0 of=/dev/null bs=128k count=4k geli init -s 2048 /dev/md0 geli attach /dev/md0 dd if=/dev/md0.eli of=/dev/null bs=128k count=4k (*) dd if=/dev/zero of=/dev/md0.eli bs=128k count=4k (*) geli detach /dev/md0 mdconfig -d -u 0 I did the same tests with my laptop Acer Aspire One D250 and the small netbook EeePC 900: Acer Aspire One D250: $ dmesg | fgrep CPU: CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.22-MHz 686-class CPU) # mdconfig -a -t swap -s512m -u 0 # dd if=/dev/zero of=/dev/md0 bs=128k count=4k 536870912 bytes transferred in 2.252701 secs (238323196 bytes/sec) # dd if=/dev/md0 of=/dev/null bs=128k count=4k 536870912 bytes transferred in 1.355759 secs (395992908 bytes/sec) # geli init -s 2048 /dev/md0 Enter new passphrase: ... # geli attach /dev/md0 Enter passphrase: # dd if=/dev/md0.eli of=/dev/null bs=128k count=4k 536868864 bytes transferred in 40.844322 secs (13144272 bytes/sec) # dd if=/dev/zero of=/dev/md0.eli bs=128k count=4k 536868864 bytes transferred in 43.093812 secs (12458143 bytes/sec) # geli detach /dev/md0 # mdconfig -d -u 0 EeePC 900 # dmesg | fgrep CPU: CPU: Intel(R) Celeron(R) M processor 900MHz (900.11-MHz 686-class CPU) # mdconfig -a -t swap -s512m -u 1 # dd if=/dev/zero of=/dev/md1 bs=128k count=4k 536870912 bytes transferred in 2.072289 secs (259071449 bytes/sec) # dd if=/dev/md1 of=/dev/null bs=128k count=4k 536870912 bytes transferred in 1.439256 secs (373019761 bytes/sec) # # geli init -s 2048 /dev/md1 Enter new passphrase: Reenter new passphrase: ... # geli attach /dev/md1 Enter passphrase: # dd if=/dev/md1.eli of=/dev/null bs=128k count=4k 536868864 bytes transferred in 35.093015 secs (15298454 bytes/sec) # dd if=/dev/zero of=/dev/md1.eli bs=128k count=4k 536868864 bytes transferred in 38.044995 secs (14111419 bytes/sec) # geli detach /dev/md1 # mdconfig -d -u 1 As you can see the EeePC with it's Intel Celeron CPU of only 900 MHz is even faster then the Acer with Atom CPU; BTW: On the EeePC I run 10-CURRENT, KDE 3.5.10 and never encounter performance issues while reading, writing etc. Concerning your hint installing the systen on the second SSD of around 16 GByte (marketing GBytes :-)), the BIOS by itself is unable to boot from; one has to go (by pressing ESC) to the boot menu to pick it up as current boot device; any idea how this could be changed? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
Why? Your laptop have most probably slow CPU and it will make everything too slow if you make everything encrypted. I'd suggest some experiments - create a largish RAMdisk with and without GELI and see how the performance compares (this will be a lot faster than converting your SSD as well as saving a full-SSD erase/write cycle). right. DO TESTs. mdconfig -a -t swap -s512m -u 0 dd if=/dev/zero of=/dev/md0 bs=128k count=4k dd if=/dev/md0 of=/dev/null bs=128k count=4k geli init -s 2048 /dev/md0 geli attach /dev/md0 dd if=/dev/md0.eli of=/dev/null bs=128k count=4k (*) dd if=/dev/zero of=/dev/md0.eli bs=128k count=4k (*) geli detach /dev/md0 mdconfig -d -u 0 but from my experience intel atom have very low geli performance, esp. older models. and your laptop is atom based IMHO. result from commands marked with * on my atom based machine: [root@bk ~/NOBACKUP]# dd if=/dev/md0.eli of=/dev/null bs=128k count=4k 4095+1 records in 4095+1 records out 536868864 bytes transferred in 25.030418 secs (21448658 bytes/sec) [root@bk ~/NOBACKUP]# dd if=/dev/zero of=/dev/md0.eli bs=128k count=4k dd: /dev/md0.eli: short write on character device dd: /dev/md0.eli: end of device 4096+0 records in 4095+1 records out 536868864 bytes transferred in 26.05 secs (20609169 bytes/sec) as you can see results are awful, in spite it is CPU: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (1827.08-MHz K8-class CPU) And i actually do use geli on it, but as the only thing it does is regularly running rsync to backup several other servers, it isn't a problem it can put heavy CPU load. As for the overall SSD write rate, some time ago, I worked through minimising the write activity on the SSD in my laptop (I wrote a tool that monitors write transfers via devstat(3) and it would be possible to track down the actual modified files via kqueue(2) if necessary). I'm now down to about two chunks of about 13 transfers each per hour (due to entopy saving and ntp.drift updating). The changes were: 1) Mount the SSD filesystems as noatime forgot about this. But this is good for ANY type of storage. I run noatime everywhere and don't have problems. 2) Turn off all local syslogging (syslog is directed to another system when my laptop is at home, lost otherwise). of course, or use /tmp/ for syslog. syslog is useful even on private computer. 3) Change maillog rotation to size instead of daily i - by default, and everywhere - turn off most things from default /etc/crontab including rotation. and if you have syslog turned off or changed as i recommended you don't have maillog file produced at all so no need to rotate. i recommend turning log rotation off at all everywhere, then turn it on willingly based on actual needs. 4) Run save-entropy once per hour instead of roughly every 11 minutes. [Note that */11 means 0,11,22,33,44,55 not every 11 minute] 5) Patch the save-entropy script to reduce the write load when it's run (see PR bin/134225). 6) Use a swap-back /tmp use tmpfs and don't fear to add /var/tmp to it. As for applications - firefox generates quite a heavy write load during normal use. Moving the cache to /tmp will help but I don't think there's any complete solution. isn't simpler to just turn cache off in firefox? Also, you're probably better off running a traditional lightweight window manager than something like KDE or Gnome. Which is good recommendation on any kind of computer and disk type, not just yours. another recomendation - why you everywhere put DOS/MBR partitions? it's just a mess and completely useless unless you run windoze on the same disk. when using whole device filesystem just clean head (dd if=/dev/zero of=/dev/device bs=1m count=1) and then just do newfs if now just bsdlabel -w device, bsdlabel -e device and possibly bsdlabel -B device it's that simple ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On 26 May 2012 15:01, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Why? Your laptop have most probably slow CPU and it will make everything too slow if you make everything encrypted. I'd suggest some experiments - create a largish RAMdisk with and without GELI and see how the performance compares (this will be a lot faster than converting your SSD as well as saving a full-SSD erase/write cycle). right. DO TESTs. mdconfig -a -t swap -s512m -u 0 dd if=/dev/zero of=/dev/md0 bs=128k count=4k dd if=/dev/md0 of=/dev/null bs=128k count=4k geli init -s 2048 /dev/md0 geli attach /dev/md0 dd if=/dev/md0.eli of=/dev/null bs=128k count=4k (*) dd if=/dev/zero of=/dev/md0.eli bs=128k count=4k (*) geli detach /dev/md0 mdconfig -d -u 0 but from my experience intel atom have very low geli performance, esp. older models. and your laptop is atom based IMHO. result from commands marked with * on my atom based machine: [root@bk ~/NOBACKUP]# dd if=/dev/md0.eli of=/dev/null bs=128k count=4k 4095+1 records in 4095+1 records out 536868864 bytes transferred in 25.030418 secs (21448658 bytes/sec) [root@bk ~/NOBACKUP]# dd if=/dev/zero of=/dev/md0.eli bs=128k count=4k dd: /dev/md0.eli: short write on character device dd: /dev/md0.eli: end of device 4096+0 records in 4095+1 records out 536868864 bytes transferred in 26.05 secs (20609169 bytes/sec) as you can see results are awful, in spite it is CPU: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (1827.08-MHz K8-class CPU) And i actually do use geli on it, but as the only thing it does is regularly running rsync to backup several other servers, it isn't a problem it can put heavy CPU load. As for the overall SSD write rate, some time ago, I worked through minimising the write activity on the SSD in my laptop (I wrote a tool that monitors write transfers via devstat(3) and it would be possible to track down the actual modified files via kqueue(2) if necessary). I'm now down to about two chunks of about 13 transfers each per hour (due to entopy saving and ntp.drift updating). The changes were: 1) Mount the SSD filesystems as noatime forgot about this. But this is good for ANY type of storage. I run noatime everywhere and don't have problems. 2) Turn off all local syslogging (syslog is directed to another system when my laptop is at home, lost otherwise). of course, or use /tmp/ for syslog. syslog is useful even on private computer. 3) Change maillog rotation to size instead of daily i - by default, and everywhere - turn off most things from default /etc/crontab including rotation. and if you have syslog turned off or changed as i recommended you don't have maillog file produced at all so no need to rotate. i recommend turning log rotation off at all everywhere, then turn it on willingly based on actual needs. 4) Run save-entropy once per hour instead of roughly every 11 minutes. [Note that */11 means 0,11,22,33,44,55 not every 11 minute] 5) Patch the save-entropy script to reduce the write load when it's run (see PR bin/134225). 6) Use a swap-back /tmp use tmpfs and don't fear to add /var/tmp to it. I would fear to add /var/tmp-- /var/tmp should persist across reboots. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
use tmpfs and don't fear to add /var/tmp to it. I would fear to add /var/tmp-- /var/tmp should persist across reboots. Chris as i noted - check your case.in my case it is not a problem. it your it may. Never blindly follow rules, good practices etc.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On 26 May 2012 16:04, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: use tmpfs and don't fear to add /var/tmp to it. I would fear to add /var/tmp-- /var/tmp should persist across reboots. Chris as i noted - check your case.in my case it is not a problem. it your it may. Never blindly follow rules, good practices etc.. If you have read every line of source code of every port you've installed, as well as /usr/src that's a great idea. If not, it's a bad idea, and you'll get some weird failure at some point, and it will be difficult to help you. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On 5/24/12 5:35 AM, Warren Block wrote: On Wed, 23 May 2012, Tim Kientzle wrote: On May 22, 2012, at 7:40 AM, Warren Block wrote: On Tue, 22 May 2012, Matthias Apitz wrote: El día Tuesday, May 22, 2012 a las 07:42:18AM -0600, Warren Block escribió: On Tue, 22 May 2012, Matthias Apitz wrote: El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk...@gmail.com escribió: Do not use MBR (or manually do all to align). 63 - not 4k aligned. To create the above shown partition layout I have not used gpart(8); I just said: # fdisk -I /dev/ada0 # fdisk -B /dev/ada0 ... What is wrong with this procedure? The filesystem partitions end up at locations that aren't even multiples of 4K. This can reduce performance. How much probably depends on the SSD. But this is then rather a bug in fdisk(8) and not a PEBKAC, or? :-) A bug in the design of MBR. Which probably can be forgiven, considering when it was created and the other problems with it. :) gpart's alignment option can be used with MBR slices and bsdlabel partitions. GPart's alignment option doesn't work for MBR slices. It rounds to the requested alignment, and then rounds again to the track size, which defaults to 63 sectors. There's an example in my proposed rewrite of the Handbook RAID1 section: http://www.wonkity.com/~wblock/mirror/book.html The slice starts at block 126, two blocks shy of 4K alignment. With the added two blocks for the bsdlabel, all of the FreeBSD partitions end up aligned at even 4K multiples. A filesystem in the raw slice would be misaligned. Presumably the answer is well don't do that, then (always use a bsdlabel with MBR), or some trick to skip a couple of blocks like gnop. If there are any mistakes in that example, please help me correct them to avert steps 4 and 5 of the traditional commit process (4: apologize, and 5: fix and recommit). I'm not convinced this is a bug in the design of MBR. I don't think anything in the MBR design requires that partitions be track-aligned. I meant bug in the sense of a missing feature. MBR may not have a provision for fixed alignment, but to its credit, doesn't prevent it either. WYYY back when disk drives and BIOS cared about this the size of a track was signalled past various scope barriers to the actual driver by setting the sectors per-track and heads-per-drive to the maximum values for that actual drive.. i.e. we assumed that the partition ENDED on a cylinder boundary and used that to extrapolate the actual geometry, which the driver actually needed to be able to drive the driver correctly. (a block number had to be divided into cyls and heads to get teh right place to go to.) none of that is true any more on any drive we care about and even if it was we can now read bios tables. so we can stick the damned partitions where ever we want, and Even the BIOS can find them (since mid 90's).. yeah I wrote it.. about time to remove it.. take that 63/255 out and shoot it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On 2012-May-18 22:54:43 +0200, Dimitry Andric d...@freebsd.org wrote: Be sure to use -t enable when creating the filesystem: Only if your SSD supports TRIM. Some consumer-grade SSDs don't and get very confused if sent TRIM commands. mine do. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
- Original Message - From: Wojciech Puchar woj...@wojtek.tensor.gdynia.pl On 2012-May-18 22:54:43 +0200, Dimitry Andric d...@freebsd.org wrote: Be sure to use -t enable when creating the filesystem: Only if your SSD supports TRIM. Some consumer-grade SSDs don't and get very confused if sent TRIM commands. mine do. The disk also has be be connected to a disk arch which supports BIO_DELETE which ATM is only ata unless your running HEAD which also has support in da Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
mine do. The disk also has be be connected to a disk arch which supports BIO_DELETE which ATM is only ata unless your running HEAD which also has support in da FreeBSD 9 support it and it do works. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
El día Saturday, May 19, 2012 a las 08:09:01PM +0200, Matthias Apitz escribió: My EeePC netbook shows for the two SSD: $ uname -a FreeBSD tiny 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r226986: Tue Nov 1 14:27:40 CET 2011 guru@caracas:/usr/obj/usr/src/sys/GENERIC i386 $ gpart show ... Talking about another question, related to file systems on SSD: My netbook with the two SSD has file systems mounted as: $ df -kh Filesystem SizeUsed Avail Capacity Mounted on /dev/ada0s1a3.7G567M3.1G15%/ /dev/ada1s1a 14G8.7G5.9G60%/usr/local /dev/md0125M 88k115M 0%/tmp Below /usr/local is also my (one and only) HOME dir; I'm on the way to reinstall all with 10-CURRENT and I'd like to crypt the partition /dev/ada1s1a with geli(8). Any objections against running geli(8) on SSD? Should I split /dev/ada1 into two separate partitions, one for real /usr/local and one for my HOME and only crypt this with geli(8)? I think it would be good to crypt my HOME on a netbook. Thanks matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
Talking about another question, related to file systems on SSD: My netbook with the two SSD has file systems mounted as: $ df -kh Filesystem SizeUsed Avail Capacity Mounted on /dev/ada0s1a3.7G567M3.1G15%/ /dev/ada1s1a 14G8.7G5.9G60%/usr/local /dev/md0125M 88k115M 0%/tmp try tmpfs instead od md backed filesystem for /tmp. Really it is better. Below /usr/local is also my (one and only) HOME dir; I'm on the way to reinstall all with 10-CURRENT and I'd like to crypt the partition /dev/ada1s1a with geli(8). Any objections against running geli(8) on SSD? NONE. As i see you have one of these famous laptops with 4+16GB SSDs. they are quite slow (they have pendrive/SD style stupid translation hardware) i would recommend reducing writes even more eg. change syslog.conf to: *.* -/var/log/messages (all to one file, no forced sync) You may put /var/tmp in ramdisk too, but it break few things (doesn't matter for me) Should I split /dev/ada1 into two separate partitions, one for real /usr/local and one for my HOME and only crypt this with geli(8)? i would make / on 16GB SSD (including /usr, /usr/local, don't divide to partitions) and geli encrypted home on 4GB SSD (whole device). if sometimes 4GB would be too little for /home then you would manually move things that don't need encryption somewhere else. Why? Your laptop have most probably slow CPU and it will make everything too slow if you make everything encrypted. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On Fri, 25 May 2012, Matthias Apitz wrote: Talking about another question, related to file systems on SSD: My netbook with the two SSD has file systems mounted as: $ df -kh Filesystem SizeUsed Avail Capacity Mounted on /dev/ada0s1a3.7G567M3.1G15%/ /dev/ada1s1a 14G8.7G5.9G60%/usr/local /dev/md0125M 88k115M 0%/tmp Below /usr/local is also my (one and only) HOME dir; I'm on the way to reinstall all with 10-CURRENT and I'd like to crypt the partition /dev/ada1s1a with geli(8). Any objections against running geli(8) on SSD? Not that I know of. The encryption happens before the write, so it won't (shouldn't) cause any extra writes. Be prepared for a performance drop. If you have a CPU with AESNI, it helps. Should I split /dev/ada1 into two separate partitions, one for real /usr/local and one for my HOME and only crypt this with geli(8)? Hard to say, but I think that encrypting only the necessary data would be better for netbooks with relatively slow CPUs. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On 2012-May-25 22:46:10 +0200, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Should I split /dev/ada1 into two separate partitions, one for real /usr/local and one for my HOME and only crypt this with geli(8)? i would make / on 16GB SSD (including /usr, /usr/local, don't divide to partitions) and geli encrypted home on 4GB SSD (whole device). if sometimes 4GB would be too little for /home then you would manually move things that don't need encryption somewhere else. This may be a worthwhile suggestion. Why? Your laptop have most probably slow CPU and it will make everything too slow if you make everything encrypted. I'd suggest some experiments - create a largish RAMdisk with and without GELI and see how the performance compares (this will be a lot faster than converting your SSD as well as saving a full-SSD erase/write cycle). As for the overall SSD write rate, some time ago, I worked through minimising the write activity on the SSD in my laptop (I wrote a tool that monitors write transfers via devstat(3) and it would be possible to track down the actual modified files via kqueue(2) if necessary). I'm now down to about two chunks of about 13 transfers each per hour (due to entopy saving and ntp.drift updating). The changes were: 1) Mount the SSD filesystems as noatime 2) Turn off all local syslogging (syslog is directed to another system when my laptop is at home, lost otherwise). 3) Change maillog rotation to size instead of daily 4) Run save-entropy once per hour instead of roughly every 11 minutes. [Note that */11 means 0,11,22,33,44,55 not every 11 minute] 5) Patch the save-entropy script to reduce the write load when it's run (see PR bin/134225). 6) Use a swap-back /tmp As for applications - firefox generates quite a heavy write load during normal use. Moving the cache to /tmp will help but I don't think there's any complete solution. Also, you're probably better off running a traditional lightweight window manager than something like KDE or Gnome. -- Peter Jeremy pgpxd8fhB1HUY.pgp Description: PGP signature
RE: proper newfs options for SSD disk
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Tim Kientzle Sent: Thursday, May 24, 2012 12:49 AM To: Warren Block Cc: freebsd-hackers@freebsd.org; Matthias Apitz Subject: Re: proper newfs options for SSD disk GPart's alignment option doesn't work for MBR slices. It rounds to the requested alignment, and then rounds again to the track size, which defaults to 63 sectors. I'm not convinced this is a bug in the design of MBR. I don't think anything in the MBR design requires that partitions be track-aligned. Tim It really doesn't. This is old school thinking based around minimizing seek and rotation time on slow multiplatter HDDs. It also helped the redundant superblock layout scheme of UFS make that spiral striping down a set of disk platters. My bet is no one has ever bothered to rethink this in the 25 years since ... Andrew Duane Juniper Networks +1 978-589-0551 (o) +1 603-770-7088 (m) adu...@juniper.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On Wed, 23 May 2012, Tim Kientzle wrote: On May 22, 2012, at 7:40 AM, Warren Block wrote: On Tue, 22 May 2012, Matthias Apitz wrote: El día Tuesday, May 22, 2012 a las 07:42:18AM -0600, Warren Block escribió: On Tue, 22 May 2012, Matthias Apitz wrote: El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk...@gmail.com escribió: Do not use MBR (or manually do all to align). 63 - not 4k aligned. To create the above shown partition layout I have not used gpart(8); I just said: # fdisk -I /dev/ada0 # fdisk -B /dev/ada0 ... What is wrong with this procedure? The filesystem partitions end up at locations that aren't even multiples of 4K. This can reduce performance. How much probably depends on the SSD. But this is then rather a bug in fdisk(8) and not a PEBKAC, or? :-) A bug in the design of MBR. Which probably can be forgiven, considering when it was created and the other problems with it. :) gpart's alignment option can be used with MBR slices and bsdlabel partitions. GPart's alignment option doesn't work for MBR slices. It rounds to the requested alignment, and then rounds again to the track size, which defaults to 63 sectors. There's an example in my proposed rewrite of the Handbook RAID1 section: http://www.wonkity.com/~wblock/mirror/book.html The slice starts at block 126, two blocks shy of 4K alignment. With the added two blocks for the bsdlabel, all of the FreeBSD partitions end up aligned at even 4K multiples. A filesystem in the raw slice would be misaligned. Presumably the answer is well don't do that, then (always use a bsdlabel with MBR), or some trick to skip a couple of blocks like gnop. If there are any mistakes in that example, please help me correct them to avert steps 4 and 5 of the traditional commit process (4: apologize, and 5: fix and recommit). I'm not convinced this is a bug in the design of MBR. I don't think anything in the MBR design requires that partitions be track-aligned. I meant bug in the sense of a missing feature. MBR may not have a provision for fixed alignment, but to its credit, doesn't prevent it either.___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On 2012-May-18 22:54:43 +0200, Dimitry Andric d...@freebsd.org wrote: Be sure to use -t enable when creating the filesystem: Only if your SSD supports TRIM. Some consumer-grade SSDs don't and get very confused if sent TRIM commands. -- Peter Jeremy pgp2LuXn5iRWb.pgp Description: PGP signature
Re: proper newfs options for SSD disk
On May 22, 2012, at 7:40 AM, Warren Block wrote: On Tue, 22 May 2012, Matthias Apitz wrote: El día Tuesday, May 22, 2012 a las 07:42:18AM -0600, Warren Block escribió: On Tue, 22 May 2012, Matthias Apitz wrote: El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk...@gmail.com escribió: Do not use MBR (or manually do all to align). 63 - not 4k aligned. To create the above shown partition layout I have not used gpart(8); I just said: # fdisk -I /dev/ada0 # fdisk -B /dev/ada0 ... What is wrong with this procedure? The filesystem partitions end up at locations that aren't even multiples of 4K. This can reduce performance. How much probably depends on the SSD. But this is then rather a bug in fdisk(8) and not a PEBKAC, or? :-) A bug in the design of MBR. Which probably can be forgiven, considering when it was created and the other problems with it. :) gpart's alignment option can be used with MBR slices and bsdlabel partitions. GPart's alignment option doesn't work for MBR slices. It rounds to the requested alignment, and then rounds again to the track size, which defaults to 63 sectors. I'm not convinced this is a bug in the design of MBR. I don't think anything in the MBR design requires that partitions be track-aligned. Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk...@gmail.com escribió: My EeePC netbook shows for the two SSD: $ uname -a FreeBSD tiny 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r226986: Tue Nov 1 14:27:40 CET 2011 guru@caracas:/usr/obj/usr/src/sys/GENERIC i386 $ gpart show = 63 7880481 ada0 MBR (3.8G) 63 7880481 1 freebsd [active] (3.8G) = 63 31522113 ada1 MBR (15G) 63 31522113 1 freebsd [active] (15G) = 0 7880481 ada0s1 BSD (3.8G) 0 16 - free - (8.0k) 16 7880465 1 freebsd-ufs (3.8G) = 0 31522113 ada1s1 BSD (15G) 016 - free - (8.0k) 16 31522097 1 freebsd-ufs (15G) Do not use MBR (or manually do all to align). 63 - not 4k aligned. Hi, To create the above shown partition layout I have not used gpart(8); I just said: # fdisk -I /dev/ada0 # fdisk -B /dev/ada0 # bsdlabel -w ada0s1 auto # bsdlabel -B ada0s1 changed partition a from unused to 4.2BSD as partition type: # setenv EDITOR /usr/bin/vi # bsdlabel -e ada0s1 created the future root-filesystem on it # newfs -m 0 -o space /dev/ada0s1a The 2nd SSD was formated like this: # dd if=/dev/zero of=/dev/ada1 count=2 # fdisk -I /dev/ada1 # newfs -m 0 -o space /dev/ada1s1a # echo /dev/ada1s1a /usr/local ufs rw,noatime 1 1 /etc/fstab # mount /usr/local What is wrong with this procedure? Thanks matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On Tue, 22 May 2012, Matthias Apitz wrote: El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk...@gmail.com escribió: Do not use MBR (or manually do all to align). 63 - not 4k aligned. To create the above shown partition layout I have not used gpart(8); I just said: # fdisk -I /dev/ada0 # fdisk -B /dev/ada0 # bsdlabel -w ada0s1 auto # bsdlabel -B ada0s1 changed partition a from unused to 4.2BSD as partition type: # setenv EDITOR /usr/bin/vi # bsdlabel -e ada0s1 created the future root-filesystem on it # newfs -m 0 -o space /dev/ada0s1a The 2nd SSD was formated like this: # dd if=/dev/zero of=/dev/ada1 count=2 # fdisk -I /dev/ada1 # newfs -m 0 -o space /dev/ada1s1a # echo /dev/ada1s1a /usr/local ufs rw,noatime 1 1 /etc/fstab # mount /usr/local What is wrong with this procedure? The filesystem partitions end up at locations that aren't even multiples of 4K. This can reduce performance. How much probably depends on the SSD.___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
El día Tuesday, May 22, 2012 a las 07:42:18AM -0600, Warren Block escribió: On Tue, 22 May 2012, Matthias Apitz wrote: El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk...@gmail.com escribió: Do not use MBR (or manually do all to align). 63 - not 4k aligned. To create the above shown partition layout I have not used gpart(8); I just said: # fdisk -I /dev/ada0 # fdisk -B /dev/ada0 ... What is wrong with this procedure? The filesystem partitions end up at locations that aren't even multiples of 4K. This can reduce performance. How much probably depends on the SSD. But this is then rather a bug in fdisk(8) and not a PEBKAC, or? :-) matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On Tue, 22 May 2012, Matthias Apitz wrote: El día Tuesday, May 22, 2012 a las 07:42:18AM -0600, Warren Block escribió: On Tue, 22 May 2012, Matthias Apitz wrote: El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk...@gmail.com escribió: Do not use MBR (or manually do all to align). 63 - not 4k aligned. To create the above shown partition layout I have not used gpart(8); I just said: # fdisk -I /dev/ada0 # fdisk -B /dev/ada0 ... What is wrong with this procedure? The filesystem partitions end up at locations that aren't even multiples of 4K. This can reduce performance. How much probably depends on the SSD. But this is then rather a bug in fdisk(8) and not a PEBKAC, or? :-) A bug in the design of MBR. Which probably can be forgiven, considering when it was created and the other problems with it. :) gpart's alignment option can be used with MBR slices and bsdlabel partitions.___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
What is wrong with this procedure? The filesystem partitions end up at locations that aren't even multiples of 4K. This can reduce performance. How much probably depends on the SSD. well in my case it is a multiply of any number you like [root@wojtek ~]# bsdlabel ada0 # /dev/ada0: 8 partitions: # size offsetfstype [fsize bsize bps/cpg] a: 117231408 04.2BSD0 0 0 c: 117231408 0unused0 0 # raw part, don't edit ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
You may be able to find the exact erase block size in the technical documentation of your specific SSD. But the manufacturers don't always tell. :) b) small fragments (like 1KB) to reduce space usage, as there is no seeking so it will not slow down but save space on relatively small SSD I don't think you would want to write lots of very small fragments to any SSD. :) i do - i have quite a lot of small files. with 4kB fragments i am losing 10% of space. but found it is right settings - Sandforce controller actually manages data with 4kB blocks. c) anything else? Be sure to use -t enable when creating the filesystem: -t enable | disable Turn on/off the TRIM enable flag. If enabled, and if the under- lying device supports the BIO_DELETE command, the file system will send a delete request to the underlying device for each freed block. The trim enable flag is typically set when the underlying device uses flash-memory as the device can use the delete command to pre-zero or at least avoid copying blocks that have been deleted. already done. thanks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
El día Saturday, May 19, 2012 a las 10:40:32AM +0200, User Wojtek escribió: You may be able to find the exact erase block size in the technical documentation of your specific SSD. But the manufacturers don't always tell. :) ... Hi, Some weeks ago in the context of Openmoko (my Linux based cellphone) I came across to this very interesting article about file systems and SSD; even if the article is in Linux context, it contains useful information about how SSD behaves when updating blocks on SSD. https://lwn.net/Articles/428584/ I have to admit, that I run an EeePC 900 netbook for many years now (with now FreeBSD 10-CURRENT) and the only special option for the SSD (the EeePC has only two SSD) is -noatime on mounting. But this is just a small netbook to read stuff or write something when I'm in town and does not need performance tweaking. HIH matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
El día Sunday, May 20, 2012 a las 03:00:46AM +0900, rozhuk...@gmail.com escribió: Partition must be aligned to: # gpart show = 34 62533229 ada0 GPT (29G) 34 6- free - (3.0k) - for align 40 512 1 freebsd-boot (256k) - size 4k aligned 552 62532648 2 freebsd-ufs (29G) - size 4k aligned 6253320063- free - (31k) My EeePC netbook shows for the two SSD: $ uname -a FreeBSD tiny 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r226986: Tue Nov 1 14:27:40 CET 2011 guru@caracas:/usr/obj/usr/src/sys/GENERIC i386 $ gpart show = 63 7880481 ada0 MBR (3.8G) 63 7880481 1 freebsd [active] (3.8G) = 63 31522113 ada1 MBR (15G) 63 31522113 1 freebsd [active] (15G) = 0 7880481 ada0s1 BSD (3.8G) 0 16 - free - (8.0k) 16 7880465 1 freebsd-ufs (3.8G) = 0 31522113 ada1s1 BSD (15G) 016 - free - (8.0k) 16 31522097 1 freebsd-ufs (15G) matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: proper newfs options for SSD disk
My EeePC netbook shows for the two SSD: $ uname -a FreeBSD tiny 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r226986: Tue Nov 1 14:27:40 CET 2011 guru@caracas:/usr/obj/usr/src/sys/GENERIC i386 $ gpart show = 63 7880481 ada0 MBR (3.8G) 63 7880481 1 freebsd [active] (3.8G) = 63 31522113 ada1 MBR (15G) 63 31522113 1 freebsd [active] (15G) = 0 7880481 ada0s1 BSD (3.8G) 0 16 - free - (8.0k) 16 7880465 1 freebsd-ufs (3.8G) = 0 31522113 ada1s1 BSD (15G) 016 - free - (8.0k) 16 31522097 1 freebsd-ufs (15G) Do not use MBR (or manually do all to align). 63 - not 4k aligned. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
proper newfs options for SSD disk
what are proper settings a) 4kB fragments so everything is 4k aligned? SSD drives itself reports as 512 byte blocks, but it is recomenned constantly on many places about 4K alignment for SSD. b) small fragments (like 1KB) to reduce space usage, as there is no seeking so it will not slow down but save space on relatively small SSD c) anything else? i use b) now. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On 2012-05-18 22:11, User Wojtek wrote: what are proper settings a) 4kB fragments so everything is 4k aligned? SSD drives itself reports as 512 byte blocks, but it is recomenned constantly on many places about 4K alignment for SSD. That 4k alignment is most likely meant for so-called advanced format hard drives (the good old magnetic platter ones); these present 512 byte sectors to the ATA interface, but use 4096 byte sectors internally. With SSDs however, you cannot automatically tell what their erase block size is. Some of them use 128kB, others 256kB, and there are probably also devices with variable erase block sizes. You may be able to find the exact erase block size in the technical documentation of your specific SSD. But the manufacturers don't always tell. :) b) small fragments (like 1KB) to reduce space usage, as there is no seeking so it will not slow down but save space on relatively small SSD I don't think you would want to write lots of very small fragments to any SSD. :) c) anything else? Be sure to use -t enable when creating the filesystem: -t enable | disable Turn on/off the TRIM enable flag. If enabled, and if the under- lying device supports the BIO_DELETE command, the file system will send a delete request to the underlying device for each freed block. The trim enable flag is typically set when the underlying device uses flash-memory as the device can use the delete command to pre-zero or at least avoid copying blocks that have been deleted. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
