Henrik /KaarPoSoft wrote: > On 11/06/12 18:49, Bruce Dubbs wrote: >> Henrik /KaarPoSoft wrote: >>> On 11/05/12 17:12, Bruce Dubbs wrote: >>>> For an SSD drive, I suggest getting gptdisk (fdisk syntax) or gparted >>>> (challenging syntax) and partitioning the drive as a gpt drive. >>> >>> I have been building on an old 32bit box with rotating disks. >>> I am considering buying a new 64bit box with SSD. >>> >>> So I would like to know why you suggest GPT for SSD? >>> I know - in general - differences between legacy MBR and GPR, but what >>> specifics may be related to SSD vs rotating? >> >> MSDOS partitions make some assumptions about cylinder/track/head that >> are not valid for SSDs. The legacy partition format my work, but why >> not use the modern one? > Thanks! I did not know this... > Maybe it is time for me to move on to GPT.. >>>> For an ssd drive, you will want to disable atime *after* completing >>>> LFS. >>> >>> Why after? >>> How about relatime? >> >> There are some issues with Makefiles that have come up in the past >> when noatime is specified on the LFS build partition. This just >> avoids potential problems. >> >> What I did when I installed my SSD drive was to build on a standard >> disk and then copy /mnt/lfs/* to a partition on the new drive. I also >> wanted to minimize the number of writes to the SSD, so I created >> additional partitions for /var and /tmp in addition to my normal ones >> for /boot, /home, and /usr/src. swap is also on a standard disk. >> >> For the root partition I use: >> >> /dev/sdc2 / ext4 noatime,discard,data=writeback 1 1 >> >> For grub, I use: >> >> /vmlinuz-3.5.2-lfs-72 root=/dev/sdc2 rootfstype=ext4 ro \ >> raid=noautodetect rootflags=data=writeback >> > Thanks for the insight! >>> --- oOo --- >>> >>> If I ever get a new 64bit box with SSD, I was thinking about: >>> Using an insane amount of swap space and creating a tmpfs and building >>> there... >>> But maybe Linux' disk buffering is good enough to just build off an SSD >>> directory, hoping for Linux to keep most of it in memory? >>> >>> Any insights on this approach? >> >> Anytime you need swap, it slows things down. If you have a large >> amount of RAM, it might be an interesting experiment though. I >> wouldn't recommend it for new users as adding more complexity and >> potential volatility would have a potential for new problems that >> first time users don't need. > > Well, what I am really after is this: > If I have, say, a rotating disk, a 512G SSD, 16G of RAM, and want to > build LFS and some BLFS (KaarPux, really), what would be the optimal way > (optimal meaning fast build, but not wearing out SSD): > - just having LFS on a SSD partition, and leaving it up to Linux to use > the RAM for buffering > - creating a tmpfs (with suffiicient swap backup), and building there...
Well if you have a mount point of /mnt/lfs, you can try doing: mount -t tmpfs -o rw,size=4G tmpfs /mnt/lfs mkdir /mnt/lfs/sources cp -a <sources dir> /mnt/lfs/sources I'd think that 4G would be plenty. After building, don't forget to copy everything to a permanent location. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
