TeXLive merge into FreeBSD ports tree - FreeBSD project idea
Hi FreeBSD fellows, Those who are using LaTeX on FreeBSD must know that tetex has been discontinued years ago and that TeXLive is now recommended, however TeXLive has never been merged in the ports tree on FreeBSD and that tetex is still used on FreeBSD ports. Although there have been some "customized" work so that FreeBSD users can install and use TeXLive on FreeBSD machine (for example, http://code.google.com/p/freebsd-texlive/wiki/Installing), this is quite confusing and may still cause conflict on the system side when using or maintaining it. There has also been years of gossips that a Japanese developer Hiroki Sato (hrs@freebsd) has been working on this matter for the last years and therefore the FreeBSD admin panel don't want anyone else to work on this and merge it into the ports tree. I actually contacted Hiroki Sato in the beginning of last year (2011) regarding this, and in his reply he said that there had been several technical issues but most of them had been solved and almost ready to merge into the port tree, and that he was planning to go forward after the 8.2/7.4 releases (one or two weeks later from that time stage) are out. However, more than a year has passed since then and still nothing happened. I tried to contact him several times after that (email, tweet, etc) but haven't heard anything back from him at all. Is TeXLive really going to be merged into the FreeBSD ports tree as Hiroki Sato mentioned previously? Or is this just a myth?? I am now thinking that this should be put into the "FreeBSD Project ideas List" [http://wiki.freebsd.org/IdeasPage]. Regards, Sam ___ 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 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"
BIO_DELETE equivalent for file on FFS filesystem
is it possible. suppose i have 1GB file with my data and 100 1 megabyte parts of it is no longer needed. i could reorganize that file to take 900MB or... can i call some system function to "punch" holes? ___ 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 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"
