Re: [gentoo-user] Cannot see Grub menu
On Mon, 13 Aug 2012 02:43:44 +0100, Peter Humphrey wrote: It's easy enough: its = belonging to it; it's = it is/was/has. The apostrophe denotes a missing letter or two, not possession. The confusion arises because, when used with a name, an apostrophe is needed for a possessive. Of course, if you refer to everyone as it, the confusion disappears :) It is an understandable error, unlike grocers' apostrophe's, which crop up everywhere and are far more grating for me. -- Neil Bothwick Don't let your mind wander, it's too little to be let out alone. signature.asc Description: PGP signature
Re: [gentoo-user] new installation (ssd, new udev, grub2)
On Sun, 12 Aug 2012 14:11:37 -0400, Allan Gottlieb wrote: I have one of those. But I decided to stick with traditional DOS partitioning style and grub instead of GPT and grub2. I am leaning toward traditional partitioning, but with grub2. Do those two not mix well? GRUB2 works fine with MBR partition tables. But if you're starting from scratch, you may as well use GPT and get rid of the legacy MBR limitations and fragility. -- Neil Bothwick Procedure: (n.) a method of performing a program sub-task in an inefficient way by extensively using the stack instead of a GOTO. signature.asc Description: PGP signature
[gentoo-user] Sandbox vs userpriv
What's the disadvantage of compiling in sandbox instead of compiling directly with userpriv?
[gentoo-user] Re: Sandbox vs userpriv
On Aug 13, 2012 2:19 PM, Nilesh Govindrajan cont...@nileshgr.com wrote: What's the disadvantage of compiling in sandbox instead of compiling directly with userpriv? *advantage
Re: [gentoo-user] Cannot see Grub menu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.08.2012 05:10, Dale wrote: Mark Knecht wrote: All of that is the OS, not grub which is in the MBR I think. emerge grub-static and then do the install as per the boot loader instructions in the manual. It will likely work fine then. Good luck. When I did my install, I used grub-static too. I never tried the plain one but was told it could have issues with 64 bit. OP. The config files should be fine as far as using the old ones. Just run the install commands again. You know, grub, root, setup etc. Dale :-) :-) As far as I recall the issues are with 64 bit nomultilib only. I think I used grub-legacy on amd64 multilib without issues, though I'm not sure since I use grub2 since 1.98 came out (without issues, by the way) WKR Hinnerk -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQKMZwAAoJEJwwOFaNFkYc3bQIAM8QxtfGR4+wjvJsnTw4Bw32 gPCZxp8UwNfydmO64IM/7INw6gwCbi7LWaleiuh+pDDWWKBLze4zGwtuY7BU4/TU +RTr03ckTSBy/neKgJUmFA3D+wuBQtb+f0Hayd5iWybzWNRcMwhfhAKvYTB/xeVX 6kCFPtMcDWsMkU8kpqsZEUr6q1PFqmxmcgpGRoRE3EO0i5uf3bFyyQa+TIbhAjoF 3a+AtmsRgBKONP8DGDkF1al8xZiPHreYGGoDKh+9MVytil8mbeea9GhLRXsiPuDw YCHLkhsH0A6duVOkJ4r4scCB2iU0sJXVFgTn9dfxXpNj6iCnu2a8rFe6rYzvwec= =W8iT -END PGP SIGNATURE-
Re: [gentoo-user] Re: Sandbox vs userpriv
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13.08.2012 10:50, Nilesh Govindrajan wrote: On Aug 13, 2012 2:19 PM, Nilesh Govindrajan cont...@nileshgr.com wrote: What's the disadvantage of compiling in sandbox instead of compiling directly with userpriv? *advantage I think the advantage is that you can compile as root with some kind of protection. ;) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQKMcgAAoJEJwwOFaNFkYco+8H/RpzlTRsA2pcBobv/L81B0J3 UQN8pDOwjaafm0rrjOFFrYG3XPDRML9dv0STULCqcpbtLFjdbmWmbLzn0DCDopbG mu2yd+ZCac36KKtGJfBLJjKiJz3NwuAMkfpGcUqFK0EaeHkmYLYVi7yWEL9C9j+H IATc2BJ4HFDgK5VJEYwFK+AlPwqr/Rkepsy38wId8hjKeQCCpsJ/C32we162aiuH dP2OyfPrrXf0Jkb+9gTuXOlhPCgIlE7eDUfD/S77ysdGG2j6JzDzyPlk2BNz2P+S 5OQTqx2a/FvEU+JtyOEoSM1Ng4fvODfq+26G+T7Mn1mPvND6Eb0U4d+KjHJVuME= =vAHc -END PGP SIGNATURE-
Re: [gentoo-user] Re: Sandbox vs userpriv
Nilesh Govindrajan wrote: On Aug 13, 2012 2:19 PM, Nilesh Govindrajan cont...@nileshgr.com mailto:cont...@nileshgr.com wrote: What's the disadvantage of compiling in sandbox instead of compiling directly with userpriv? *advantage I found this: http://devmanual.gentoo.org/general-concepts/sandbox/ That help any? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Cannot see Grub menu
As far as I recall the issues are with 64 bit nomultilib only. I think I used grub-legacy on amd64 multilib without issues, though I'm not sure since I use grub2 since 1.98 came out (without issues, by the way) You are correct. On a no-multilib 64 bit system you cannot compile grub:1 - you must use grub-static or grub:2
Re: [gentoo-user] Re: Sandbox vs userpriv
On Mon, Aug 13, 2012 at 4:50 AM, Nilesh Govindrajan cont...@nileshgr.comwrote: On Aug 13, 2012 2:19 PM, Nilesh Govindrajan cont...@nileshgr.com wrote: What's the disadvantage of compiling in sandbox instead of compiling directly with userpriv? *advantage If you do things like parallel builds (-j applied to emerge, not just make), a sandbox can help keep the build environment consistent throughout a build. (And if that's not a feature that's currently in sandbox, it's one where an extension of which is being discussed in -dev right now, and being worked on by a few people.) The other thing sandbox gives you is some protection from badly-written build systems, such as ones which go out and modify files outside of explicitly-allowed paths and the like, or try installing files before 'make install'...that kind of thing. -- :wq
Re: [gentoo-user] new installation (ssd, new udev, grub2)
On Mon, Aug 13, 2012 at 4:06 AM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 12 Aug 2012 14:11:37 -0400, Allan Gottlieb wrote: I have one of those. But I decided to stick with traditional DOS partitioning style and grub instead of GPT and grub2. I am leaning toward traditional partitioning, but with grub2. Do those two not mix well? GRUB2 works fine with MBR partition tables. But if you're starting from scratch, you may as well use GPT and get rid of the legacy MBR limitations and fragility. I'm not dissing GPT...but what's fragile about MBR? -- :wq
Re: [gentoo-user] new installation (ssd, new udev, grub2)
On Mon, Aug 13 2012, Neil Bothwick wrote: On Sun, 12 Aug 2012 14:11:37 -0400, Allan Gottlieb wrote: GRUB2 works fine with MBR partition tables. But if you're starting from scratch, you may as well use GPT and get rid of the legacy MBR limitations and fragility. OK, but what about EFI? That seems to involve more work and the writeup suggests that you need a separate (FAT32) boot partition? allan
Re: [gentoo-user] new installation (ssd, new udev, grub2)
On Sun, Aug 12 2012, Alan McKinnon wrote: On Sun, 12 Aug 2012 14:11:37 -0400 Allan Gottlieb gottl...@nyu.edu wrote: On Fri, Aug 10 2012, Alan McKinnon wrote: You also don't need an IO scheduler - ssd access is random like RAM, no heads moving in and out so no sector ordering to worry about. Configure the scheduler as NOOP in kernel config if all drives are ssd's I believe dell with be throwing in a removable spinning disk that can be user swapped with the dvd so I should probably keep the I/O scheduler. You can set the scheduler per-device too, more info here: https://wiki.archlinux.org/index.php/Solid_State_Drives#I.2FO_Scheduler Someone else reported though that Deadline scheduler can actually performs better, I also read that somewhere. Maybe you should do some initial tests yourself before deciding Yes, that sounds like a good idea and the article you just mentioned looks to be quite helpful. thanks, allan
Re: [gentoo-user] new installation (ssd, new udev, grub2)
On Mon, 13 Aug 2012 08:17:23 -0400, Michael Mol wrote: GRUB2 works fine with MBR partition tables. But if you're starting from scratch, you may as well use GPT and get rid of the legacy MBR limitations and fragility. I'm not dissing GPT...but what's fragile about MBR? The MBR contains only details of the primary partitions, the logical partition details are scattered over the disk, and there's no backup of either. Making your own backup is non-trivial, even if you bother. GPT puts all the partition information in one block, and keeps a backup copy elsewhere (rather like filesystems do with superblocks). That makes GPT more resilient to corruption in the first place and easier to recover if things do go bad. Remember that GPT was designed with the benefit of decades of hindsight over the limitations of DOS partition tables. -- Neil Bothwick In plumbing, a straight flush is better than a full house. signature.asc Description: PGP signature
[gentoo-user] Fast file system for cache directory with lot's of files
Howdy gentooers, I am looking for a filesystem that perfomes well for a cache directory. Here's some data on that dir: - cache for prescaled images files + metadata files - nested directory structure ( 20/2022/202231/*files* ) - about 20GB - 100.000 directories - about 2 million files The system has 2x Intel Xon Quad-cores (Nehalem), 16GB of RAM and two 10.000rpm hard drives running a RAID1. Up until now I was using ext4 with noatime, but I am not happy with it's performence. Finding and deleting old files with 'find' is incredible slow, so I am looking for a filesystem that performs better. First candiate that came to mind was reiserfs, but last time I tried it, it became slower over time (fragmentation?). Currently I am running a test with btrfs and so far I am quiet happy with it as it is much faster in my use case. Do you guys have any other suggestions? How about JFS? I used that on my old NAS box because of it's low cpu usage. Should I give reiser4 a try, or better leave it be given Hans Reiser's current status? Thx in advance, Mike
Re: [gentoo-user] Re: Sandbox vs userpriv
On Mon 13 Aug 2012 05:37:27 PM IST, Michael Mol wrote: On Mon, Aug 13, 2012 at 4:50 AM, Nilesh Govindrajan cont...@nileshgr.com mailto:cont...@nileshgr.com wrote: On Aug 13, 2012 2:19 PM, Nilesh Govindrajan cont...@nileshgr.com mailto:cont...@nileshgr.com wrote: What's the disadvantage of compiling in sandbox instead of compiling directly with userpriv? *advantage If you do things like parallel builds (-j applied to emerge, not just make), a sandbox can help keep the build environment consistent throughout a build. (And if that's not a feature that's currently in sandbox, it's one where an extension of which is being discussed in -dev right now, and being worked on by a few people.) The other thing sandbox gives you is some protection from badly-written build systems, such as ones which go out and modify files outside of explicitly-allowed paths and the like, or try installing files before 'make install'...that kind of thing. -- :wq I see. Actually I came up with this question because dev-lang/php was emitting some errors when I was building with sandbox enabled (I never disabled it actually). I guess I'll enable it again and disable when some ebuilds trouble. -- Nilesh Govindrajan http://nileshgr.com
Re: [gentoo-user] Fast file system for cache directory with lot's of files
On Mon 13 Aug 2012 06:46:53 PM IST, Michael Hampicke wrote: Howdy gentooers, I am looking for a filesystem that perfomes well for a cache directory. Here's some data on that dir: - cache for prescaled images files + metadata files - nested directory structure ( 20/2022/202231/*files* ) - about 20GB - 100.000 directories - about 2 million files The system has 2x Intel Xon Quad-cores (Nehalem), 16GB of RAM and two 10.000rpm hard drives running a RAID1. Up until now I was using ext4 with noatime, but I am not happy with it's performence. Finding and deleting old files with 'find' is incredible slow, so I am looking for a filesystem that performs better. First candiate that came to mind was reiserfs, but last time I tried it, it became slower over time (fragmentation?). Currently I am running a test with btrfs and so far I am quiet happy with it as it is much faster in my use case. Do you guys have any other suggestions? How about JFS? I used that on my old NAS box because of it's low cpu usage. Should I give reiser4 a try, or better leave it be given Hans Reiser's current status? Thx in advance, Mike You should have a look at xfs. I used to use ext4 earlier, traversing through /usr/portage used to be very slow. When I switched xfs, speed increased drastically. This might be kind of unrelated, but makes sense. -- Nilesh Govindrajan http://nileshgr.com
Re: [gentoo-user] Fast file system for cache directory with lot's of files
You should have a look at xfs. I used to use ext4 earlier, traversing through /usr/portage used to be very slow. When I switched xfs, speed increased drastically. This might be kind of unrelated, but makes sense. I guess traversing through directories may be faster with XFS, but in my experience ext4 perfoms better than XFS in regard to operations (cp, rm) on small files. I read that there are some tuning options for XFS and small files, but never tried it. But if somone seconds XFS I will try it too.
Re: [gentoo-user] Fast file system for cache directory with lot's of files
On Aug 13, 2012 9:01 PM, Michael Hampicke mgehampi...@gmail.com wrote: You should have a look at xfs. I used to use ext4 earlier, traversing through /usr/portage used to be very slow. When I switched xfs, speed increased drastically. This might be kind of unrelated, but makes sense. I guess traversing through directories may be faster with XFS, but in my experience ext4 perfoms better than XFS in regard to operations (cp, rm) on small files. I read that there are some tuning options for XFS and small files, but never tried it. But if somone seconds XFS I will try it too. Have you indexed your ext4 partition? # tune2fs -O dir_index /dev/your_partition # e2fsck -D /dev/your_partition Rgds,
Re: [gentoo-user] Fast file system for cache directory with lot's of files
On 13.08.2012 15:16, Michael Hampicke wrote: - about 20GB - 100.000 directories - about 2 million files The system has 2x Intel Xon Quad-cores (Nehalem), 16GB of RAM and two 10.000rpm hard drives running a RAID1. 1st thought: switch to SSDs 2nd thought: maybe lots of writes? - get a SSD for the fs metadata 3rd thought: purging old files with find? your cache system should have some kind of DB that holds that information.
Re: [gentoo-user] Fast file system for cache directory with lot's of files
Michael Hampicke wrote: You should have a look at xfs. I used to use ext4 earlier, traversing through /usr/portage used to be very slow. When I switched xfs, speed increased drastically. This might be kind of unrelated, but makes sense. I guess traversing through directories may be faster with XFS, but in my experience ext4 perfoms better than XFS in regard to operations (cp, rm) on small files. I read that there are some tuning options for XFS and small files, but never tried it. But if somone seconds XFS I will try it too. It's been a while since I messed with this but isn't XFS the one that hates power failures and such? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Fast file system for cache directory with lot's of files
Have you indexed your ext4 partition? # tune2fs -O dir_index /dev/your_partition # e2fsck -D /dev/your_partition Hi, the dir_index is active. I guess that's why delete operations take as long as they take (index has to be updated every time)
Re: [gentoo-user] Fast file system for cache directory with lot's of files
On Mon, Aug 13, 2012 at 10:42 AM, Michael Hampicke mgehampi...@gmail.comwrote: Have you indexed your ext4 partition? # tune2fs -O dir_index /dev/your_partition # e2fsck -D /dev/your_partition Hi, the dir_index is active. I guess that's why delete operations take as long as they take (index has to be updated every time) 1) Scan for files to remove 2) disable index 3) Remove files 4) enable index ? -- :wq
Re: [gentoo-user] Fast file system for cache directory with lot's of files
2012/8/13 Daniel Troeder dan...@admin-box.com On 13.08.2012 15:16, Michael Hampicke wrote: - about 20GB - 100.000 directories - about 2 million files The system has 2x Intel Xon Quad-cores (Nehalem), 16GB of RAM and two 10.000rpm hard drives running a RAID1. 1st thought: switch to SSDs 2nd thought: maybe lots of writes? - get a SSD for the fs metadata 3rd thought: purging old files with find? your cache system should have some kind of DB that holds that information. 1: SSDs are not possible atm. The machine is in a data center abroad. 2: Writes are not that much of a problem at this time. 3: Well, it's a 3rd party application that - in theory - should take care of removing old files. Sadly, it does not work as it's supposed to be, While time passes the number of orphans grow :(
Re: [gentoo-user] Fast file system for cache directory with lot's of files
I guess traversing through directories may be faster with XFS, but in my experience ext4 perfoms better than XFS in regard to operations (cp, rm) on small files. I read that there are some tuning options for XFS and small files, but never tried it. But if somone seconds XFS I will try it too. It's been a while since I messed with this but isn't XFS the one that hates power failures and such? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Well, it's the delayed allocation of XFS (which prevents fragmentation) that does not like sudden power losses :) But ext4 has that too, you can disable it though - that should be true for XFS too. But the power situation in the datacenter has never been a problem so far, and even if the cache partition get's screwed, we can always rebuild it. Takes a few hours, but it would not be the end of the world :)
Re: [gentoo-user] Fast file system for cache directory with lot's of files
On Mon 13 Aug 2012 08:28:15 PM IST, Michael Hampicke wrote: I guess traversing through directories may be faster with XFS, but in my experience ext4 perfoms better than XFS in regard to operations (cp, rm) on small files. I read that there are some tuning options for XFS and small files, but never tried it. But if somone seconds XFS I will try it too. It's been a while since I messed with this but isn't XFS the one that hates power failures and such? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Well, it's the delayed allocation of XFS (which prevents fragmentation) that does not like sudden power losses :) But ext4 has that too, you can disable it though - that should be true for XFS too. But the power situation in the datacenter has never been a problem so far, and even if the cache partition get's screwed, we can always rebuild it. Takes a few hours, but it would not be the end of the world :) Yes, XFS hates power failures. I got a giant UPS for my home desktop to use XFS because of it's excellent performance ;-) -- Nilesh Govindrajan http://nileshgr.com
Re: [gentoo-user] Fast file system for cache directory with lot's of files
Am 13.08.2012 16:52, schrieb Michael Mol: On Mon, Aug 13, 2012 at 10:42 AM, Michael Hampicke mgehampi...@gmail.comwrote: Have you indexed your ext4 partition? # tune2fs -O dir_index /dev/your_partition # e2fsck -D /dev/your_partition Hi, the dir_index is active. I guess that's why delete operations take as long as they take (index has to be updated every time) 1) Scan for files to remove 2) disable index 3) Remove files 4) enable index ? That's what I love about gentoo-users :) , I would never have thought of that myself. I will try this and see how much of an performance gain there is. Disabling the index should only require a 'mount -o remount' I guess.
Re: [gentoo-user] new installation (ssd, new udev, grub2)
On Mon, 13 Aug 2012 08:17:23 -0400 Michael Mol mike...@gmail.com wrote: On Mon, Aug 13, 2012 at 4:06 AM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 12 Aug 2012 14:11:37 -0400, Allan Gottlieb wrote: I have one of those. But I decided to stick with traditional DOS partitioning style and grub instead of GPT and grub2. I am leaning toward traditional partitioning, but with grub2. Do those two not mix well? GRUB2 works fine with MBR partition tables. But if you're starting from scratch, you may as well use GPT and get rid of the legacy MBR limitations and fragility. I'm not dissing GPT...but what's fragile about MBR? it's 30 years old, only 4 primary partitions, only 16 extended partitions, it's got that weird DOS boot flag thing, it all has to fit in one sector. I had to fix a mispartitioned disk over the weekend, this really should have been a simple mv-type operation, but because all 4 primary partitions were in use I had to disable swap and use it as a leap-frog area. It felt like I was playing 15 pieces with the disk. That's fragile - not that the disk breaks, but that it breaks my ability to set the thing up easily. Basically, mbr was built to cater for the needs of DOS-3. In the meantime, 1982 called and they want their last 30 years back. Just because we can hack workarounds into it to get it to function doesn't mean we should continue to use it. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Fast file system for cache directory with lot's of files
On Mon, Aug 13, 2012 at 11:26 AM, Michael Hampicke mgehampi...@gmail.comwrote: Am 13.08.2012 16:52, schrieb Michael Mol: On Mon, Aug 13, 2012 at 10:42 AM, Michael Hampicke mgehampi...@gmail.comwrote: Have you indexed your ext4 partition? # tune2fs -O dir_index /dev/your_partition # e2fsck -D /dev/your_partition Hi, the dir_index is active. I guess that's why delete operations take as long as they take (index has to be updated every time) 1) Scan for files to remove 2) disable index 3) Remove files 4) enable index ? That's what I love about gentoo-users :) , I would never have thought of that myself. I will try this and see how much of an performance gain there is. Disabling the index should only require a 'mount -o remount' I guess. It's the same logic as behind database programming; do a bulk modification, then update the index afterwards. The index update will take longer than that for a single file, but it has the potential to be more efficient in bulk operations. (It'd be nice if ext4 supported transactional behaviors, where you could defer index updates until after a commit, but I don't think it (or any filesystem on Linux) does.) You *should* be able to enable/disable indexes on a per-directory basis, so if your search pattern is confined, I'd go that route. -- :wq
Re: [gentoo-user] new installation (ssd, new udev, grub2)
On Mon, Aug 13, 2012 at 11:47 AM, Alan McKinnon alan.mckin...@gmail.comwrote: On Mon, 13 Aug 2012 08:17:23 -0400 Michael Mol mike...@gmail.com wrote: On Mon, Aug 13, 2012 at 4:06 AM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 12 Aug 2012 14:11:37 -0400, Allan Gottlieb wrote: I have one of those. But I decided to stick with traditional DOS partitioning style and grub instead of GPT and grub2. I am leaning toward traditional partitioning, but with grub2. Do those two not mix well? GRUB2 works fine with MBR partition tables. But if you're starting from scratch, you may as well use GPT and get rid of the legacy MBR limitations and fragility. I'm not dissing GPT...but what's fragile about MBR? it's 30 years old, only 4 primary partitions, only 16 extended partitions, it's got that weird DOS boot flag thing, it all has to fit in one sector. I had to fix a mispartitioned disk over the weekend, this really should have been a simple mv-type operation, but because all 4 primary partitions were in use I had to disable swap and use it as a leap-frog area. It felt like I was playing 15 pieces with the disk. That's fragile - not that the disk breaks, but that it breaks my ability to set the thing up easily. Basically, mbr was built to cater for the needs of DOS-3. In the meantime, 1982 called and they want their last 30 years back. Just because we can hack workarounds into it to get it to function doesn't mean we should continue to use it. You misunderstand me. I wasn't arguing that GPT wasn't perhaps more elegant than MBR and dos partitions. I wanted to know what was _fragile_ about MBR. Completely different things. -- :wq
Re: [gentoo-user] Fast file system for cache directory with lot's of files
Am 13.08.2012 16:52, schrieb Michael Mol:
On Mon, Aug 13, 2012 at 10:42 AM, Michael Hampicke
mgehampi...@gmail.com mailto:mgehampi...@gmail.com wrote:
Have you indexed your ext4 partition?
# tune2fs -O dir_index /dev/your_partition
# e2fsck -D /dev/your_partition
Hi, the dir_index is active. I guess that's why delete operations
take as long as they take (index has to be updated every time)
1) Scan for files to remove
2) disable index
3) Remove files
4) enable index
?
--
:wq
Other things to think about:
1. Play around with data=journal/writeback/ordered. IIRC, data=journal
actually used to improve performance depending on the workload as it
delays random IO in favor of sequential IO (when updating the journal).
2. Increase the journal size.
3. Take a look at `man 1 chattr`. Especially the 'T' attribute. Of
course this only helps after re-allocating everything.
4. Try parallelizing. Ext4 requires relatively few locks nowadays (since
2.6.39 IIRC). For example:
find $TOP_DIR -mindepth 1 -maxdepth 1 -print0 | \
xargs -0 -n 1 -r -P 4 -I '{}' find '{}' -type f
5. Use a separate device for the journal.
6. Temporarily deactivate the journal with tune2fs similar to MM's idea.
Regards,
Florian Philipp
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-user] Cannot see Grub menu
On Mon, Aug 13, 2012 at 09:03:38AM +0100, Neil Bothwick wrote: On Mon, 13 Aug 2012 02:43:44 +0100, Peter Humphrey wrote: It's easy enough: its = belonging to it; it's = it is/was/has. The apostrophe denotes a missing letter or two, not possession. The confusion arises because, when used with a name, an apostrophe is needed for a possessive. Of course, if you refer to everyone as it, the confusion disappears :) The proper posessive analogy here would be “her” and, of course, “his”. I guess the only reason why I'm so observant of such things is because I had to learn it from scratch starting at about 12 at school. Native speakers do as they are used to from earliest childhood. It wasn't different with me and my native tongue. $deiety, when I look at the stuff that I wrote as a child… -- Gruß | Greetings | Qapla' Please do not share anything from, with or about me with any Facebook service. Signatures are being revised, we apologise for any inconvenience.
Re: [gentoo-user] Cannot see Grub menu
On Sun, Aug 12, 2012 at 06:14:11PM -0500, Dale wrote: I have always used GRUB splashimage without genkernel and without anything special to get it going other than the correct path in /boot/grub/grub.conf; e.g. default 0 timeout 30 splashimage=(hd0,9)/boot/grub/splash.xpm.gz That's the way I used to too also. Very strange this all... Just a thought. Could it be that the text and the background is the same color? If you put white text on a white background, all you see is white which looks blank, empty or whatever you want to call it. No, because the original text “Loading Grub from Harddisk” and “Loading stage 1.5” don’t disappear. But you know what -- I just tested again in qemu (to read the text output so that I can write it here). And lo!, the menu finally appeared. Let’s see then what the next reboot will bring. -- Gruß | Greetings | Qapla' Please do not share anything from, with or about me with any Facebook service. The duration of a minute is relative. It depends on the side of the toilet door you are standing on. pgpqi78JVIyPa.pgp Description: PGP signature
Re: [gentoo-user] new installation (ssd, new udev, grub2)
On Aug 13, 2012 11:04 PM, Michael Mol mike...@gmail.com wrote: On Mon, Aug 13, 2012 at 11:47 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Mon, 13 Aug 2012 08:17:23 -0400 Michael Mol mike...@gmail.com wrote: On Mon, Aug 13, 2012 at 4:06 AM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 12 Aug 2012 14:11:37 -0400, Allan Gottlieb wrote: I have one of those. But I decided to stick with traditional DOS partitioning style and grub instead of GPT and grub2. I am leaning toward traditional partitioning, but with grub2. Do those two not mix well? GRUB2 works fine with MBR partition tables. But if you're starting from scratch, you may as well use GPT and get rid of the legacy MBR limitations and fragility. I'm not dissing GPT...but what's fragile about MBR? it's 30 years old, only 4 primary partitions, only 16 extended partitions, it's got that weird DOS boot flag thing, it all has to fit in one sector. I had to fix a mispartitioned disk over the weekend, this really should have been a simple mv-type operation, but because all 4 primary partitions were in use I had to disable swap and use it as a leap-frog area. It felt like I was playing 15 pieces with the disk. That's fragile - not that the disk breaks, but that it breaks my ability to set the thing up easily. Basically, mbr was built to cater for the needs of DOS-3. In the meantime, 1982 called and they want their last 30 years back. Just because we can hack workarounds into it to get it to function doesn't mean we should continue to use it. You misunderstand me. I wasn't arguing that GPT wasn't perhaps more elegant than MBR and dos partitions. I wanted to know what was _fragile_ about MBR. Completely different things. Well, for one, MBR has no copy, and it is not protected from corruption. GPT has 2 copies: One at the head of the disk right behind a legacy MBR, and another at the end of the disk. Both copies are protected by magic strings and CRC. Rgds,
Re: [gentoo-user] Fast file system for cache directory with lot's of files
Am 13.08.2012 19:14, schrieb Florian Philipp:
Am 13.08.2012 16:52, schrieb Michael Mol:
On Mon, Aug 13, 2012 at 10:42 AM, Michael Hampicke
mgehampi...@gmail.com mailto:mgehampi...@gmail.com wrote:
Have you indexed your ext4 partition?
# tune2fs -O dir_index /dev/your_partition
# e2fsck -D /dev/your_partition
Hi, the dir_index is active. I guess that's why delete operations
take as long as they take (index has to be updated every time)
1) Scan for files to remove
2) disable index
3) Remove files
4) enable index
?
--
:wq
Other things to think about:
1. Play around with data=journal/writeback/ordered. IIRC, data=journal
actually used to improve performance depending on the workload as it
delays random IO in favor of sequential IO (when updating the journal).
2. Increase the journal size.
3. Take a look at `man 1 chattr`. Especially the 'T' attribute. Of
course this only helps after re-allocating everything.
4. Try parallelizing. Ext4 requires relatively few locks nowadays (since
2.6.39 IIRC). For example:
find $TOP_DIR -mindepth 1 -maxdepth 1 -print0 | \
xargs -0 -n 1 -r -P 4 -I '{}' find '{}' -type f
5. Use a separate device for the journal.
6. Temporarily deactivate the journal with tune2fs similar to MM's idea.
Regards,
Florian Philipp
Trying out different journals-/options was already on my list, but the
manpage on chattr regarding the T attribute is an interesting read.
Definitely worth trying.
Parallelizing multiple finds was something I already did, but the only
thing that increased was the IO wait :) But now having read all the
suggestions in this thread, I might try it again.
Separate device for the journal is a good idea, but not possible atm
(machine is abroad in a data center)
[gentoo-user] Comparison between 32 bit and 64 bit
Hey there As I mentioned in an earlier thread, I switched from 32 to 64 bit after some convinction work done by the ML and a friend. In order to justify the switch for myself, I made some performance comparisons. So, in case anyone is interested, here are my results. The only thing I don't really like is of course the increased RAM usage. While the old installation took 400 MB of RAM after Login to KDE (Akonadi is a hog), it now takes 500. The memory meter now stands always at least at 50% (3 GB available). I will have to tune down multitasking a bit. The following items first display the command excuted (denoted by $), and then the output of time for the command; first for 32 bit and then 64 bit. All tests were done on my Core 2 Duo laptop (T7200, max. 2GHz) fixed at 1 GHz and with 3 GB of RAM. This is not a theoretical benchmark, but rather about stuff I usually to do in my every-day computing. I excluded compiling, because it involves more than just crunching. Resulting observation: there seems to be an inherent increase of about 10% in memory throughput. I was most surprised by the performance of lilypond and blender, two computing-intensive applications I tend to use regularly. I wanted to do a framerate comparison of the Java-based CPU hog Minecraft, but didn't get around to it. All the following tasks were done in ramdisk to rule out HDD hindrance. $ 7z b (7zip's own benchmark function, abridged output) 32 bit | 64 bit === RAM size:3037 MB| RAM size:3013 MB RAM usage:425 MB| RAM usage:425 MB | Dict Compressing | Decomp.| Dict Compressing | Decomp. Speed Rating | Speed Rating | Speed Rating | Speed Rating KB/s MIPS | KB/s MIPS | KB/s MIPS | KB/s MIPS | 22:1487 1446 | 19039 1719 | 22:1612 1568 | 20974 1893 23:1443 1470 | 19049 1744 | 23:1612 1642 | 20758 1900 24:1499 1612 | 18854 1749 | 24:1591 1711 | 20292 1883 25:1489 1700 | 18611 1750 | 25:1584 1809 | 20030 1884 -- Avr: 1557 1740 | 16821890 Tot: 1649 | 1786 Various compressions of the High Voltage SID collection version 56 (41356 files, 1416 folders, total dir size 307.676k according to du -s). Extract: $ unrar x hvsc.rar real0m38.582s 0m38.763s user0m36.031s 0m36.190s sys 0m2.523s0m2.496s --- neglibible Repack witz p7zip, resulting archive size 54.8 MB: $ 7za a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on hvsc.7z C64Music/ /dev/null real3m0.530s2m41.780s user5m22.359s 4m55.810s sys 2m2.973s0m3.144s --- 1/9 faster Extract from 7z: $ 7z x hvsc.7z real0m24.541s 0m21.437s user0m19.302s 0m16.929s sys 0m4.403s0m4.472s --- 1/10 faster Simple taring of the directory: $ tar cf hvsc.tar C64Music/ real0m1.334s0m1.226s user0m0.297s0m0.304s sys 0m1.020s0m0.872s --- ~1/10 faster XZing the tar, resulting archive size 54.2 MB: $ xz -k -z hvsc.tar real6m26.383s 4m31.747s user6m23.375s 4m30.969s sys 0m2.733s0m0.728s --- ~1/3 faster XZing with --extreme option (about 4% smaller archive): $ xz -e -k -z hvsc.tar real15m37.732s 10m39.348s user15m36.592s 10m38.900s sys 0m0.977s0m0.456s --- ~1/3 faster Packing in squashfs: $ mksquashfs C64Music/ hvsc.sqfs real0m57.380s 0m44.697s user1m45.136s 1m20.377s sys 0m9.059s0m6.116s --- ~1/4 faster Some memory shuffling: $ dd if=/dev/urandom of=random bs=1M count=500 real2m0.306s 1m49.348s user0m0.003s 0m0.000s sys 2m0.292s 1m49.315s --- 1/12 faster $ cp random r2 real0m1.069s 0m0.917s user0m0.000s 0m0.004s sys 0m1.067s 0m0.908s --- 1/10 faster Compile Bach's Christmas Oratorio, Tenor part, 16 pages A5: $ lilypond wo.ly real0m31.430s 0m23.737s user0m30.711s 0m23.129s sys 0m0.717s 0m0.592s --- 1/3 faster Compile Oratorio de Noël by Saint-Saëns, 4 voices, 16 pages A4: $ lilypond noel.lyk real0m41.575s 0m26.494s user0m41.177s 0m25.870s sys 0m0.390s 0m0.604s --- 1/3 faster Optimising a PNG (photo of Orion nebula, 1400x1050 pixel): $ optipng -o9 Orion.png real0m23.491s 0m21.337s user0m23.465s 0m21.281s sys 0m0.027s 0m0.008s --- 1/10 faster Encoding a video file to x264 (1280x960, 1600 frames, no sound): First pass: $ mencoder bike.flv -ovc x264 -x264encopts bitrate=2000:pass=1 -nosound -o /dev/null real1m57.379s 1m44.500s user3m48.048s 3m19.728s sys 0m0.837s 0m0.796s --- 1/8 faster
Re: [gentoo-user] Fast file system for cache directory with lot's of files
On Mon, Aug 13, 2012 at 8:16 AM, Michael Hampicke mgehampi...@gmail.com wrote: Howdy gentooers, I am looking for a filesystem that perfomes well for a cache directory. Here's some data on that dir: - cache for prescaled images files + metadata files - nested directory structure ( 20/2022/202231/*files* ) - about 20GB - 100.000 directories - about 2 million files The system has 2x Intel Xon Quad-cores (Nehalem), 16GB of RAM and two 10.000rpm hard drives running a RAID1. Up until now I was using ext4 with noatime, but I am not happy with it's performence. Finding and deleting old files with 'find' is incredible slow, so I am looking for a filesystem that performs better. First candiate that came to mind was reiserfs, but last time I tried it, it became slower over time (fragmentation?). Currently I am running a test with btrfs and so far I am quiet happy with it as it is much faster in my use case. Do you guys have any other suggestions? How about JFS? I used that on my old NAS box because of it's low cpu usage. Should I give reiser4 a try, or better leave it be given Hans Reiser's current status? I think btrfs probably is meant to provide a lot of the modern features like reiser4 or xfs (tail-packing, indexing, compression, snapshots, subvolumes, etc). Don't know if it is considered stable enough for your usage but at least it is under active development and funded by large names. I think if you would consider reiser4 as a possibility then you should consider btrfs as well.
Re: [gentoo-user] Fast file system for cache directory with lot's of files
Am Montag, 13. August 2012, 15:13:03 schrieb Paul Hartman: On Mon, Aug 13, 2012 at 8:16 AM, Michael Hampicke mgehampi...@gmail.com wrote: Howdy gentooers, I am looking for a filesystem that perfomes well for a cache directory. Here's some data on that dir: - cache for prescaled images files + metadata files - nested directory structure ( 20/2022/202231/*files* ) - about 20GB - 100.000 directories - about 2 million files The system has 2x Intel Xon Quad-cores (Nehalem), 16GB of RAM and two 10.000rpm hard drives running a RAID1. Up until now I was using ext4 with noatime, but I am not happy with it's performence. Finding and deleting old files with 'find' is incredible slow, so I am looking for a filesystem that performs better. First candiate that came to mind was reiserfs, but last time I tried it, it became slower over time (fragmentation?). Currently I am running a test with btrfs and so far I am quiet happy with it as it is much faster in my use case. Do you guys have any other suggestions? How about JFS? I used that on my old NAS box because of it's low cpu usage. Should I give reiser4 a try, or better leave it be given Hans Reiser's current status? I think btrfs probably is meant to provide a lot of the modern features like reiser4 or xfs (tail-packing, indexing, compression, snapshots, subvolumes, etc). Don't know if it is considered stable enough for your usage but at least it is under active development and funded by large names. I think if you would consider reiser4 as a possibility then you should consider btrfs as well. reiser4 has one feature btrfs and ever other is missing. atomic operations. Which is a wonderful feature. Too bad 'politics' killed reiser4. -- #163933
Re: [gentoo-user] Cannot see Grub menu
On Monday 13 Aug 2012 18:46:22 Frank Steinmetzger wrote: On Sun, Aug 12, 2012 at 06:14:11PM -0500, Dale wrote: Just a thought. Could it be that the text and the background is the same color? If you put white text on a white background, all you see is white which looks blank, empty or whatever you want to call it. No, because the original text “Loading Grub from Harddisk” and “Loading stage 1.5” don’t disappear. But you know what -- I just tested again in qemu (to read the text output so that I can write it here). And lo!, the menu finally appeared. Let’s see then what the next reboot will bring. What, without changing anything in your system? O_o Could it be a hardware problem then? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] new installation (ssd, new udev, grub2)
On Mon, 13 Aug 2012 11:55:31 -0400 Michael Mol mike...@gmail.com wrote: On Mon, Aug 13, 2012 at 11:47 AM, Alan McKinnon alan.mckin...@gmail.comwrote: On Mon, 13 Aug 2012 08:17:23 -0400 Michael Mol mike...@gmail.com wrote: On Mon, Aug 13, 2012 at 4:06 AM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 12 Aug 2012 14:11:37 -0400, Allan Gottlieb wrote: I have one of those. But I decided to stick with traditional DOS partitioning style and grub instead of GPT and grub2. I am leaning toward traditional partitioning, but with grub2. Do those two not mix well? GRUB2 works fine with MBR partition tables. But if you're starting from scratch, you may as well use GPT and get rid of the legacy MBR limitations and fragility. I'm not dissing GPT...but what's fragile about MBR? it's 30 years old, only 4 primary partitions, only 16 extended partitions, it's got that weird DOS boot flag thing, it all has to fit in one sector. I had to fix a mispartitioned disk over the weekend, this really should have been a simple mv-type operation, but because all 4 primary partitions were in use I had to disable swap and use it as a leap-frog area. It felt like I was playing 15 pieces with the disk. That's fragile - not that the disk breaks, but that it breaks my ability to set the thing up easily. Basically, mbr was built to cater for the needs of DOS-3. In the meantime, 1982 called and they want their last 30 years back. Just because we can hack workarounds into it to get it to function doesn't mean we should continue to use it. You misunderstand me. I wasn't arguing that GPT wasn't perhaps more elegant than MBR and dos partitions. I wanted to know what was _fragile_ about MBR. Completely different things. I did answer (somewhat obliquely). mbr as a single isolated unit is not especially fragile; very little software is and bits don't magically rot It's the system into which the sysadmin inserts mbr that is fragile. The whole system is fragile like an egg is fragile - it can't withstand much manhandling or moving of stuff around before some mistake wreaks everything, and that is mostly due to mbr's limits. It's not semantic nitpicking here, if the system as a unit becomes fragile as a result of part X, then the system is still fragile. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Comparison between 32 bit and 64 bit
On Mon, Aug 13, 2012 at 1:55 PM, Frank Steinmetzger war...@gmx.de wrote: As I mentioned in an earlier thread, I switched from 32 to 64 bit after some convinction work done by the ML and a friend. In order to justify the switch for myself, I made some performance comparisons. So, in case anyone is interested, here are my results. Thanks, it is always interesting to see real-world results.
Re: [gentoo-user] Comparison between 32 bit and 64 bit
Am Montag, 13. August 2012, 20:55:23 schrieb Frank Steinmetzger: Hey there As I mentioned in an earlier thread, I switched from 32 to 64 bit after some convinction work done by the ML and a friend. In order to justify the switch for myself, I made some performance comparisons. So, in case anyone is interested, here are my results. The only thing I don't really like is of course the increased RAM usage. While the old installation took 400 MB of RAM after Login to KDE (Akonadi is a hog), it now takes 500. The memory meter now stands always at least at 50% (3 GB available). I will have to tune down multitasking a bit. The following items first display the command excuted (denoted by $), and then the output of time for the command; first for 32 bit and then 64 bit. All tests were done on my Core 2 Duo laptop (T7200, max. 2GHz) fixed at 1 GHz and with 3 GB of RAM. This is not a theoretical benchmark, but rather about stuff I usually to do in my every-day computing. I excluded compiling, because it involves more than just crunching. Resulting observation: there seems to be an inherent increase of about 10% in memory throughput. I was most surprised by the performance of lilypond and blender, two computing-intensive applications I tend to use regularly. I wanted to do a framerate comparison of the Java-based CPU hog Minecraft, but didn't get around to it. All the following tasks were done in ramdisk to rule out HDD hindrance. $ 7z b (7zip's own benchmark function, abridged output) 32 bit | 64 bit === RAM size:3037 MB| RAM size:3013 MB RAM usage:425 MB| RAM usage:425 MB Dict Compressing | Decomp.| Dict Compressing | Decomp. Speed Rating | Speed Rating | Speed Rating | Speed Rating KB/s MIPS | KB/s MIPS | KB/s MIPS | KB/s MIPS 22:1487 1446 | 19039 1719 | 22:1612 1568 | 20974 1893 23:1443 1470 | 19049 1744 | 23:1612 1642 | 20758 1900 24:1499 1612 | 18854 1749 | 24:1591 1711 | 20292 1883 25:1489 1700 | 18611 1750 | 25:1584 1809 | 20030 1884 -- Avr: 1557 1740 | 16821890 Tot: 1649 | 1786 Various compressions of the High Voltage SID collection version 56 (41356 files, 1416 folders, total dir size 307.676k according to du -s). Extract: $ unrar x hvsc.rar real0m38.582s 0m38.763s user0m36.031s 0m36.190s sys 0m2.523s0m2.496s --- neglibible Repack witz p7zip, resulting archive size 54.8 MB: $ 7za a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on hvsc.7z C64Music/ /dev/null real3m0.530s2m41.780s user5m22.359s 4m55.810s sys 2m2.973s0m3.144s --- 1/9 faster Extract from 7z: $ 7z x hvsc.7z real0m24.541s 0m21.437s user0m19.302s 0m16.929s sys 0m4.403s0m4.472s --- 1/10 faster Simple taring of the directory: $ tar cf hvsc.tar C64Music/ real0m1.334s0m1.226s user0m0.297s0m0.304s sys 0m1.020s0m0.872s --- ~1/10 faster XZing the tar, resulting archive size 54.2 MB: $ xz -k -z hvsc.tar real6m26.383s 4m31.747s user6m23.375s 4m30.969s sys 0m2.733s0m0.728s --- ~1/3 faster XZing with --extreme option (about 4% smaller archive): $ xz -e -k -z hvsc.tar real15m37.732s 10m39.348s user15m36.592s 10m38.900s sys 0m0.977s0m0.456s --- ~1/3 faster Packing in squashfs: $ mksquashfs C64Music/ hvsc.sqfs real0m57.380s 0m44.697s user1m45.136s 1m20.377s sys 0m9.059s0m6.116s --- ~1/4 faster Some memory shuffling: $ dd if=/dev/urandom of=random bs=1M count=500 real2m0.306s 1m49.348s user0m0.003s 0m0.000s sys 2m0.292s 1m49.315s --- 1/12 faster $ cp random r2 real0m1.069s 0m0.917s user0m0.000s 0m0.004s sys 0m1.067s 0m0.908s --- 1/10 faster Compile Bach's Christmas Oratorio, Tenor part, 16 pages A5: $ lilypond wo.ly real0m31.430s 0m23.737s user0m30.711s 0m23.129s sys 0m0.717s 0m0.592s --- 1/3 faster Compile Oratorio de Noël by Saint-Saëns, 4 voices, 16 pages A4: $ lilypond noel.lyk real0m41.575s 0m26.494s user0m41.177s 0m25.870s sys 0m0.390s 0m0.604s --- 1/3 faster Optimising a PNG (photo of Orion nebula, 1400x1050 pixel): $ optipng -o9 Orion.png real0m23.491s 0m21.337s user0m23.465s 0m21.281s sys 0m0.027s 0m0.008s --- 1/10 faster Encoding a video file to x264 (1280x960, 1600 frames, no sound): First pass: $ mencoder bike.flv -ovc x264 -x264encopts bitrate=2000:pass=1 -nosound -o /dev/null real
Re: [gentoo-user] Comparison between 32 bit and 64 bit
On Tue, Aug 14, 2012 at 12:20:04AM +0200, Volker Armin Hemmann wrote: Am Montag, 13. August 2012, 20:55:23 schrieb Frank Steinmetzger: Hey there As I mentioned in an earlier thread, I switched from 32 to 64 bit after some convinction work done by the ML and a friend. In order to justify the switch for myself, I made some performance comparisons. So, in case anyone is interested, here are my results. The only thing I don't really like is of course the increased RAM usage. While the old installation took 400 MB of RAM after Login to KDE (Akonadi is a hog), it now takes 500. The memory meter now stands always at least at 50% (3 GB available). I will have to tune down multitasking a bit. [major snippage] so all in all you got performance improvements you had to spend several hundred of dollars for just through recompiling. Should give you food for thought. I don't understand that sentence. Where did I spend 100s of $$? Oh and the ram? Ram is cheap. Get yourseld 8gb. Costs as much as a good lunch. Nah, I won't upgrade this laptop anymore. It's 6 years old, the heatpipe is worn out, so I can't go full-power anymore, the backlight is getting weaker and the keyboard is falling apart. I don't have too little RAM, I just don't have that much by today's standard. (It came shipped with 1 Gig BTW). I'm gonna build me a nice i5-based minitower once I can afford it. *dream* What a pity though -- you just don't get 1400x1050 laptops anymore these days (or any 4:3 laptops for that matter). Or a couple of beers on friday night. I don't drink beer. ;-p -- Gruß | Greetings | Qapla' Please do not share anything from, with or about me with any Facebook service. Size does not always matter: while whales are almost extinct, the ants fare quite well. pgpvDXnOeXyag.pgp Description: PGP signature
[OT] Re: [gentoo-user] Cannot see Grub menu
On Monday 13 August 2012 09:03:38 Neil Bothwick wrote: The confusion arises because, when used with a name, an apostrophe is needed for a possessive. The confusion arises because the apostrophe has two functions, which collide in its/it's. Who can tell /a priori/ which applies in any given case? You just have to know. There's no substitute for a decent education. It is an understandable error... Indeed, which is why I don't usually rise to any particular bait. ...unlike grocers' apostrophe's, which crop up everywhere and are far more grating for me. Agreed, except that I think you mean greengrocers'. I also find that commas seem to be thrown at random into a piece of prose in the apparent hope that a few will land where they might do some good. Even Penrose is sometimes guilty of that. And don't start me on the egregious Oxford comma. Nor on the German insistence on separating the verb from the object with a comma, as though the action could proceed without something to act on. Even worse is the developing inability to distinguish between singular and plural. Not only that but the growing use of stuff shows an inability to distinguish even between what can be counted (number) and what can't (amount). I could find myself in despair if I weren't careful. -- Rgds Peter
Re: [gentoo-user] Comparison between 32 bit and 64 bit
Am Dienstag, 14. August 2012, 01:18:20 schrieb Frank Steinmetzger: On Tue, Aug 14, 2012 at 12:20:04AM +0200, Volker Armin Hemmann wrote: Am Montag, 13. August 2012, 20:55:23 schrieb Frank Steinmetzger: Hey there As I mentioned in an earlier thread, I switched from 32 to 64 bit after some convinction work done by the ML and a friend. In order to justify the switch for myself, I made some performance comparisons. So, in case anyone is interested, here are my results. The only thing I don't really like is of course the increased RAM usage. While the old installation took 400 MB of RAM after Login to KDE (Akonadi is a hog), it now takes 500. The memory meter now stands always at least at 50% (3 GB available). I will have to tune down multitasking a bit. [major snippage] so all in all you got performance improvements you had to spend several hundred of dollars for just through recompiling. Should give you food for thought. I don't understand that sentence. Where did I spend 100s of $$? you didn't. You got the equivalent of a major cpu/mobo/ram upgrade in performance improvements - for free. Oh and the ram? Ram is cheap. Get yourseld 8gb. Costs as much as a good lunch. Nah, I won't upgrade this laptop anymore. It's 6 years old, the heatpipe is worn out, so I can't go full-power anymore, the backlight is getting weaker and the keyboard is falling apart. I don't have too little RAM, I just don't have that much by today's standard. (It came shipped with 1 Gig BTW). I'm gonna build me a nice i5-based minitower once I can afford it. *dream* What a pity though -- you just don't get 1400x1050 laptops anymore these days (or any 4:3 laptops for that matter). Or a couple of beers on friday night. I don't drink beer. ;-p -- #163933
Re: [gentoo-user] Comparison between 32 bit and 64 bit
On Tue, Aug 14, 2012 at 02:23:25AM +0200, Volker Armin Hemmann wrote: so all in all you got performance improvements you had to spend several hundred of dollars for just through recompiling. Should give you food for thought. I don't understand that sentence. Where did I spend 100s of $$? you didn't. You got the equivalent of a major cpu/mobo/ram upgrade in performance improvements - for free. Ahh, now I see that subclause in the middle there. :) -- Gruß | Greetings | Qapla' Please do not share anything from, with or about me with any Facebook service. Poverty is not a disgrace, but a bloody nuisance. pgpQRbZdFjzV6.pgp Description: PGP signature
Re: [gentoo-user] Comparison between 32 bit and 64 bit
Am Dienstag, 14. August 2012, 02:39:44 schrieb Frank Steinmetzger: On Tue, Aug 14, 2012 at 02:23:25AM +0200, Volker Armin Hemmann wrote: so all in all you got performance improvements you had to spend several hundred of dollars for just through recompiling. Should give you food for thought. I don't understand that sentence. Where did I spend 100s of $$? you didn't. You got the equivalent of a major cpu/mobo/ram upgrade in performance improvements - for free. Ahh, now I see that subclause in the middle there. :) yeah, I am babbling and writing crap. It is 3 in the morning and I am sick. Not a good combination for well thought, grammatically correct writing. -- #163933
Re: [gentoo-user] Fast file system for cache directory with lot's of files
I think btrfs probably is meant to provide a lot of the modern features like reiser4 or xfs Unfortunately btrfs is still generally slower than ext4 for example. Checkout http://openbenchmarking.org/, eg http://openbenchmarking.org/s/ext4%20btrfs The OS will use any spare RAM for disk caching, so if there's not much else running on that box, most of your content will be served from RAM. It may be that whatever fs you choose wont make that much of a difference anyways.
