Has anyone started seriously testing and tinkering with openSUSE on SSD drives? The prices are dropping and I'm thinking it's time to move over to SSD for my main drive - I'm thinking I'll do this around the release of 11.3. I've been doing some reading, and see a lot of conflicting info... in one place I see notes that you must set noatime and you cannot(should not) put the swap on the SSD drive.... among many others... like running a cron job to clear or write memory on a regular basis (something to that effect was discussed here, but without any clear reason why you'd need to so this or what was actually being doen.... at least not that I saw. Most of the rest of the information is at least 2 years old and mostly focuses on panic over the limited read/write cycles on SSDs... one camp says no problems, just install as usual... the other says no way.. disable this and that, and put home on a reg drive, and and and. So.. what's the concensus here? Just install as normal now? Treat the drives as a reg drive? Or handle with care and assume I'm venturing into fail country? C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2010-05-31 at 17:51 +0200, C wrote:
Has anyone started seriously testing and tinkering with openSUSE on SSD drives?
The prices are dropping and I'm thinking it's time to move over to SSD for my main drive - I'm thinking I'll do this around the release of 11.3. I've been doing some reading, and see a lot of conflicting info... in one place I see notes that you must set noatime and you cannot(should not) put the swap on the SSD drive.... among many others... like running a cron job to clear or write memory on a regular basis (something to that effect was discussed here, but without any clear reason why you'd need to so this or what was actually being doen.... at least not that I saw.
Most of the rest of the information is at least 2 years old and mostly focuses on panic over the limited read/write cycles on SSDs... one camp says no problems, just install as usual... the other says no way.. disable this and that, and put home on a reg drive, and and and.
So.. what's the concensus here? Just install as normal now? Treat the drives as a reg drive? Or handle with care and assume I'm venturing into fail country?
C.
Well, i just started installing 11.2 as my new firewall & co on an ssd. Nothing special to it. # fdisk -l /dev/sda Disk /dev/sda: 32.0 GB, 32017047552 bytes 255 heads, 63 sectors/track, 3892 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x990347ca Device Boot Start End Blocks Id System /dev/sda1 * 1 20 160618+ 83 Linux /dev/sda2 21 3892 31101840 8e Linux LVM # hwinfo --disk 41: IDE 00.0: 10600 Disk [Created at block.243] UDI: /org/freedesktop/Hal/devices/storage_serial_OCZ_SOLID2_DD61M52KEA50ZQO8QVJV Unique ID: 3OOL.+NT5W5MHKY7 Parent ID: w7Y8.UKoiXLHVNY4 SysFS ID: /class/block/sda SysFS BusID: 0:0:0:0 SysFS Device Link: /devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0 Hardware Class: disk Model: "OCZ-SOLID2" Device: "OCZ-SOLID2" Revision: "1.5" Serial ID: "DD61M52KEA50ZQO8QVJV" Driver: "ata_piix", "sd" Device File: /dev/sda Device Files: /dev/sda, /dev/block/8:0, /dev/disk/by-id/ata-OCZ-SOLID2_DD61M52KEA50ZQO8QVJV, /dev/disk/by-id/scsi-SATA_OCZ-SOLID2_DD61M52KEA50ZQO8QVJV, /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0, /dev/disk/by-id/edd-int13_dev80 Device Number: block 8:0-8:15 BIOS id: 0x80 Geometry (Logical): CHS 3892/255/63 Size: 62533296 sectors a 512 bytes Geometry (BIOS EDD): CHS 62037/16/63 Size (BIOS EDD): 62533296 sectors Geometry (BIOS Legacy): CHS 1024/255/63 Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #17 (IDE interface) Boots fast, no noise, low power consumption. Just a bit more expensive than a regular sata-drive One *might* consider avoiding swap on a ssd-drive, but i rather have a worn-out drive than OOM on my firewall. (allthough i don't expect swapping will ever happen with 4GB mem) hw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hans Witvliet wrote:
One *might* consider avoiding swap on a ssd-drive, but i rather have a worn-out drive than OOM on my firewall. (allthough i don't expect swapping will ever happen with 4GB mem)
Hehe, my firewall has only 24Mb and no swap enabled. -- Per Jessen, Zürich (12.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2010-05-31 at 23:32 +0200, Hans Witvliet wrote: What about this stuff about aligning the disk blocks on a 4k boundary to match the physical disk access? If that is not done when the disk is formatted, there could be a performance penalty. I did not think openSUSE did this. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 2010-06-01 at 08:09 +0200, Roger Oberholtzer wrote:
On Mon, 2010-05-31 at 23:32 +0200, Hans Witvliet wrote:
What about this stuff about aligning the disk blocks on a 4k boundary to match the physical disk access? If that is not done when the disk is formatted, there could be a performance penalty. I did not think openSUSE did this.
you see things in the wrong perspective, imho. For ages we use 512 byte blocks. If you start using larger blocks you might gain some speed, but it doesn't mean there is a performance penalty when using 512 byte blocks. When doing a 20GB read, l get: 20480000000 bytes (20 GB) copied, 124.208 s, 165 MB/s just a bit (185MB/s) faster when doing smaller transfers. Good enough for a simple firewall, for me atleast... What should i gain with 4K blocks? I think this is more intended for ordinary drives with rotating platters... hw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 2010-06-01 at 09:06 +0200, Hans Witvliet wrote:
On Tue, 2010-06-01 at 08:09 +0200, Roger Oberholtzer wrote:
On Mon, 2010-05-31 at 23:32 +0200, Hans Witvliet wrote:
What about this stuff about aligning the disk blocks on a 4k boundary to match the physical disk access? If that is not done when the disk is formatted, there could be a performance penalty. I did not think openSUSE did this.
you see things in the wrong perspective, imho.
For ages we use 512 byte blocks. If you start using larger blocks you might gain some speed, but it doesn't mean there is a performance penalty when using 512 byte blocks.
SSD disks do not use 4K blocks. Some have a 512k compatibility mode. But that is buffering in the disk software - the physical access is 4K no matter.
When doing a 20GB read, l get: 20480000000 bytes (20 GB) copied, 124.208 s, 165 MB/s just a bit (185MB/s) faster when doing smaller transfers. Good enough for a simple firewall, for me atleast...
What should i gain with 4K blocks? I think this is more intended for ordinary drives with rotating platters...
The disk cannot read/write 512K blocks. It must read/write 4K blocks. Because of the way this works, if the disk has it's 4K blocks aligned differently than the disk formatting, reading/writing can require more accesses than necessary. I have been looking for an interesting article I read recently about this. The effect was not huge, so it is not a show stopper. But decreasing unnecessary disk access is usually not a bad thing. It seemed that the 'solution' was that the Linux disk formatting program just had to be sure the logical 4k blocks align with the physical disk blocks. The jury is out on which Linux distros do this. It is something that must be done when the disk is formatted. I do not know where openSUSE is on this. Is this something in 11.3? -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
The disk cannot read/write 512K blocks. It must read/write 4K blocks. Because of the way this works, if the disk has it's 4K blocks aligned differently than the disk formatting, reading/writing can require more accesses than necessary. I have been looking for an interesting article I read recently about this. The effect was not huge, so it is not a show stopper. But decreasing unnecessary disk access is usually not a bad thing.
It seemed that the 'solution' was that the Linux disk formatting program just had to be sure the logical 4k blocks align with the physical disk blocks. The jury is out on which Linux distros do this. It is something that must be done when the disk is formatted.
I do not know where openSUSE is on this. Is this something in 11.3?
Do a search on openfate - I'm certain I've seen one or two requests on this topic. Maybe wrt partitioning. -- Per Jessen, Zürich (11.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 6/1/2010 3:06 AM, Hans Witvliet wrote:
On Tue, 2010-06-01 at 08:09 +0200, Roger Oberholtzer wrote:
On Mon, 2010-05-31 at 23:32 +0200, Hans Witvliet wrote:
What about this stuff about aligning the disk blocks on a 4k boundary to match the physical disk access? If that is not done when the disk is formatted, there could be a performance penalty. I did not think openSUSE did this.
you see things in the wrong perspective, imho.
For ages we use 512 byte blocks. If you start using larger blocks you might gain some speed, but it doesn't mean there is a performance penalty when using 512 byte blocks.
When doing a 20GB read, l get: 20480000000 bytes (20 GB) copied, 124.208 s, 165 MB/s just a bit (185MB/s) faster when doing smaller transfers. Good enough for a simple firewall, for me atleast...
What should i gain with 4K blocks? I think this is more intended for ordinary drives with rotating platters... hw
The badness probably has more to do with the erase block size in ssd's and the finite number of write-ops per block in ssd's. If the ssd deals in 4k chunks, but you only want to modify a 512byte chunk, or even a misaligned 4k chunk, perhaps you are forcing the ssd internally to do several other things to do something with the other 3 x 512 bytes just to accomplish the outward result of modifying the 1 x 512 bytes you were interested in. Whereas if you tell the OS/filesystem to deal in the same 4k chunks and properly aligned, then you remove all extra work the ssd must do, and you probably double the life of the ssd since there is finite number to times a given block can be written or erased, and you are no longer making the ssd do multiple writes to accomplish what looks like one write outwardly. Heck, without proper alignment you might end up making the ssd write over two 4k internal ssd blocks (consuming the finite supply of write ops) just to change 20 bytes if they are in a 512byte filesystem block which spans over a 4k internal ssd block boundary. That is causing both unnecessary io operations overhead, and halving or thirding the life of the ssd. See: http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd’s-erase-block-size http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s... including the several links within that article more than the article itself. It is _never_ correct to dismiss technical issues without knowing what they are. It is _especially_ never correct to counsel others to do so. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
What about this stuff about aligning the disk blocks on a 4k boundary to match the physical disk access? If that is not done when the disk is formatted, there could be a performance penalty. I did not think openSUSE did this.
It probably doesn't matter much on a firewall machine. -- Per Jessen, Zürich (11.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2010-05-31 at 17:51 +0200, C wrote:
Has anyone started seriously testing and tinkering with openSUSE on SSD drives? The prices are dropping and I'm thinking it's time to move over to SSD for my main drive - I'm thinking I'll do this around the release of 11.3. I've been doing some reading, and see a lot of conflicting info... in one place I see notes that you must set noatime and you cannot(should not)
"noatime" or a near work-alike [relatime?] is the default in modern kernels.
Most of the rest of the information is at least 2 years old and mostly focuses on panic over the limited read/write cycles on SSDs... one
In large part because the hype has dyed down. SSDs offer some specific advantages in some cases; and none in most cases. Just a more expensive solution for [less] mass-storage. Unless you have a real I/O bottleneck problem - don't bother. Most of the people I've met who are using them are doing so because they are the cool-new-thing. Unless you do careful reasearch on the unit to buy they don't necessarily even save you any power [assuming you are using a laptop and care about power].
camp says no problems, just install as usual... the other says no way.. disable this and that, and put home on a reg drive, and and and. So.. what's the concensus here? Just install as normal now? Treat the drives as a reg drive? Or handle with care and assume I'm venturing into fail country?
Spinning drives are cheap and reliable. Stick with spinning drives.
--
Adam Tauno Williams
On Tue, Jun 1, 2010 at 12:58, Adam Tauno Williams wrote:
11.3. I've been doing some reading, and see a lot of conflicting info... in one place I see notes that you must set noatime and you cannot(should not)
"noatime" or a near work-alike [relatime?] is the default in modern kernels.
This is one of those conflicts of information I see. Some people say it's a default so no worries.. then the next says.. no way, you have to set this option or... the world will end... or your SSD will fail... whichever comes first.
In large part because the hype has dyed down. SSDs offer some specific advantages in some cases; and none in most cases. Just a more expensive solution for [less] mass-storage. Unless you have a real I/O bottleneck problem - don't bother. Most of the people I've met who are using them are doing so because they are the cool-new-thing.
There is that, but... on computers I've seen running on SSD drives, the boot cycle, and application startup is a LOT faster. it's not just a little bit better... it's a couple orders of magnitude faster.... which is why I'm looking into moving to SSD. My root install plus home directory could fit comfortably on a 64 or even a 32Gb drive. I have a couple of Tb of disks for storage, and that's all they do now... store files.. multimedia (music, video), web related stuff, game source files, work projects etc etc. All stuff that is accessed once in a while.. not on a reg basis. My thinking is... it might be possible to see a performance boost by switching over to SSD for the OS plus basic /home... thus the questions.. and the research I'm doing before I run out and buy the first SSD on the shelf. C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 2010-06-01 at 13:25 +0200, C wrote:
On Tue, Jun 1, 2010 at 12:58, Adam Tauno Williams wrote:
11.3. I've been doing some reading, and see a lot of conflicting info... in one place I see notes that you must set noatime and you cannot(should not)
"noatime" or a near work-alike [relatime?] is the default in modern kernels.
This is one of those conflicts of information I see. Some people say it's a default so no worries.. then the next says.. no way, you have to set this option or... the world will end... or your SSD will fail... whichever comes first.
The world will end - the question is just "when?" :) There is no harm in using the noatime setting; I've been using noatime on all my production servers and my own laptop/workstation for years with no problem. No modern application cares about atime and it isn't even useful for auditing.
In large part because the hype has dyed down. SSDs offer some specific advantages in some cases; and none in most cases. Just a more expensive solution for [less] mass-storage. Unless you have a real I/O bottleneck problem - don't bother. Most of the people I've met who are using them are doing so because they are the cool-new-thing. There is that, but... on computers I've seen running on SSD drives, the boot cycle, and application startup is a LOT faster.
Really? I've seen demonstrations of that and not been impressed. You could get, IMNSHO, a bigger performance boost by spending that same amount of money on a lot more RAM. I've got spinning disks and 6GB of RAM and apps start pretty close to instantly. An order-of-magnitude difference I doubt would even be noticeable.
it's not just a little bit better... it's a couple orders of magnitude faster.... which is why I'm looking into moving to SSD.
If you believe that is true then it makes sense to use SSD.
--
Adam Tauno Williams
On Tue, Jun 1, 2010 at 13:53, Adam Tauno Williams wrote:
This is one of those conflicts of information I see. Some people say it's a default so no worries.. then the next says.. no way, you have to set this option or... the world will end... or your SSD will fail... whichever comes first.
The world will end - the question is just "when?" :)
Or, it's already ended and no one noticed :-)
There is no harm in using the noatime setting; I've been using noatime on all my production servers and my own laptop/workstation for years with no problem. No modern application cares about atime and it isn't even useful for auditing.
Hmmm I think it's time for me to read up more on atime. I need to understand it better.
Really? I've seen demonstrations of that and not been impressed. You could get, IMNSHO, a bigger performance boost by spending that same amount of money on a lot more RAM. I've got spinning disks and 6GB of RAM and apps start pretty close to instantly. An order-of-magnitude difference I doubt would even be noticeable.
That's the bit that is confusing me. I've seen uber fast startup, and application launch times and seen people chatting about exactly that on forums (granted the majority were Windows users, but some Linux too). Then I go somewhere else in my random searches, and the next discussion or comment is essentially the same as yours.... benchmarks show there is essentially zero difference. I wonder, are those benchmarks on the cheapy drives (which are def slower) or the higher priced and faster drives?
If you believe that is true then it makes sense to use SSD.
I want to believe... oh wait, that's X-Files. I'm still undecided about the SSD performance... the comments here have been... interesting. I still have time to research it :-) C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 2010-06-01 at 14:04 +0200, C wrote:
On Tue, Jun 1, 2010 at 13:53, Adam Tauno Williams wrote:
This is one of those conflicts of information I see. Some people say it's a default so no worries.. then the next says.. no way, you have to set this option or... the world will end... or your SSD will fail... whichever comes first. The world will end - the question is just "when?" :) Or, it's already ended and no one noticed :-)
Possibly several times over.
There is no harm in using the noatime setting; I've been using noatime on all my production servers and my own laptop/workstation for years with no problem. No modern application cares about atime and it isn't even useful for auditing. Hmmm I think it's time for me to read up more on atime. I need to understand it better.
https://lwn.net/Articles/244830/ https://lwn.net/Articles/244829/ <quote> i cannot over-emphasise how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, _combined_. </quote> This is true. If they had atime, and a slow I/O bus, and then they set noatime [because they thought they should on an SSD] - that might explain some of the performance improvement.
Really? I've seen demonstrations of that and not been impressed. You could get, IMNSHO, a bigger performance boost by spending that same amount of money on a lot more RAM. I've got spinning disks and 6GB of RAM and apps start pretty close to instantly. An order-of-magnitude difference I doubt would even be noticeable. That's the bit that is confusing me. I've seen uber fast startup,
I've no doubt start-up times are faster, that I'd suspect, would be a real-world difference. As for me, start-up is pretty fast anyway, I don't startup that often (twice a day?)... so I just don't get what the big deal is. Faster is nice, but really [for me anyway] it doesn't matter.
too). Then I go somewhere else in my random searches, and the next discussion or comment is essentially the same as yours.... benchmarks show there is essentially zero difference.
Yep.
I wonder, are those benchmarks on the cheapy drives (which are def slower) or the higher priced and faster drives?
For good SSD's there is a real difference when you are doing a high rate of *random* and *small* read/writes. Like with an RDBMS, especially for a database journal/log partition. Sifting the good from the lame is arduous work and best left to experienced testers. As for normal file-system access - which is mostly big-block reads... I've seen nothing convincing. Once the systems cache is filled the benefit evaporates [so initial booting *is* certainly faster, and then you also have many services spinning up at once]. But once you are logged in and working, just about everything you want should be at least partially in RAM already.
If you believe that is true then it makes sense to use SSD. I want to believe... oh wait, that's X-Files. I'm still undecided about the SSD performance... the comments here have been... interesting. I still have time to research it :-)
--
Adam Tauno Williams
On Tue, Jun 1, 2010 at 14:33, Adam Tauno Williams wrote:
<quote> i cannot over-emphasise how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, _combined_. </quote>
This is true.
If they had atime, and a slow I/O bus, and then they set noatime [because they thought they should on an SSD] - that might explain some of the performance improvement.
Hmmmm interesting. Well, I just added noatime to the fstab for my various partitions (root, home, etc.) and did a mount -o remount on each partition. Now the test :-) is there any noticeable difference.
I've no doubt start-up times are faster, that I'd suspect, would be a real-world difference. As for me, start-up is pretty fast anyway, I don't startup that often (twice a day?)... so I just don't get what the big deal is. Faster is nice, but really [for me anyway] it doesn't matter.
Yes true. On my mian machine it goes through a startup cycle once a week at most.. more usual is once every month or two.
For good SSD's there is a real difference when you are doing a high rate of *random* and *small* read/writes. Like with an RDBMS, especially for a database journal/log partition.
Aha, that would do it. Interesting information so far... and now with noatime set on all my partitions... well, I have to wait a bit to see if it helps.
you also have many services spinning up at once]. But once you are logged in and working, just about everything you want should be at least partially in RAM already.
On my main machine I've got 8GB of RAM. The difference between say.. 2Gb of RAM and 8GB is night and day with Linux. C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, Jun 1, 2010 at 9:18 AM, C
On Tue, Jun 1, 2010 at 14:33, Adam Tauno Williams wrote:
<quote> i cannot over-emphasise how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, _combined_. </quote>
This is true.
If they had atime, and a slow I/O bus, and then they set noatime [because they thought they should on an SSD] - that might explain some of the performance improvement.
Hmmmm interesting. Well, I just added noatime to the fstab for my various partitions (root, home, etc.) and did a mount -o remount on each partition. Now the test :-) is there any noticeable difference.
I've no doubt start-up times are faster, that I'd suspect, would be a real-world difference. As for me, start-up is pretty fast anyway, I don't startup that often (twice a day?)... so I just don't get what the big deal is. Faster is nice, but really [for me anyway] it doesn't matter.
Yes true. On my mian machine it goes through a startup cycle once a week at most.. more usual is once every month or two.
For good SSD's there is a real difference when you are doing a high rate of *random* and *small* read/writes. Like with an RDBMS, especially for a database journal/log partition.
Aha, that would do it. Interesting information so far... and now with noatime set on all my partitions... well, I have to wait a bit to see if it helps.
you also have many services spinning up at once]. But once you are logged in and working, just about everything you want should be at least partially in RAM already.
On my main machine I've got 8GB of RAM. The difference between say.. 2Gb of RAM and 8GB is night and day with Linux.
C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
FYI: I started to put some info together related to SSDs and trim that adds to this discussion. http://en.opensuse.org/User:Gregfreemyer The new wiki is supposed to go live shortly, so I haven't tried to figure out how to create a SSD page in the new wiki. If someone knows and to do that, feel free to move my content there and this thread has had some useful info that could also be added to the page. Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retriev... The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Adam Tauno Williams said the following on 06/01/2010 07:53 AM:
On Tue, 2010-06-01 at 13:25 +0200, C wrote:
There is that, but... on computers I've seen running on SSD drives, the boot cycle, and application startup is a LOT faster.
Really? I've seen demonstrations of that and not been impressed. You could get, IMNSHO, a bigger performance boost by spending that same amount of money on a lot more RAM. I've got spinning disks and 6GB of RAM and apps start pretty close to instantly. An order-of-magnitude difference I doubt would even be noticeable.
*sigh* One the whole I agree with Adam, but there are exceptions. Back in 1984 at a local meeting of the UNIX Users Group someone was preaching the virtues of a new disk board that had a huge RAM cache. It gave that 'orders of magnitude' performance increase to the then extant versions of UNIX, most notably SCO. I spoke out against it. I was at that time a kernel hacker and specialised in disk drivers. The SCO OS at that time had just the one (V7) file system. Data writes were async, structure writes were sync. The 'bottom half' of the driver didn't know which, so this cache board didn't know which either. As a result, a crash that could be recovered with FSCK one a normal system could not be recovered with the cache board. I pointed out that spending the money on the same amount of RAM for the system would be more productive for a number of reasons, including less swapping. UNIX did good cache management and buffering. It has only got better. The cache board enthusiast was not there the next month, nor the one after that. When he did turn up he admitted he'd been away because he'd been rebuilding his file systems after a crash. OK, so this doesn't apply to SSD. And SSD is a moving target. But some points do hold. Adding more RAM will always help simply because it reduces the amount of disk activity - even if you are not swapping and paging. There's more buffer for directory and inode when searching file names to open files. RAM is faster than the fastest SSD, even if the SSD were faster than the RAM because of the overhead of going though the drivers & interface :-) Buy RAM when you can. Heck, it cheap enough these day! The exception? Laptops. Only so many slots and a comparatively low top limit on the amount of RAM. Unlike desktops, laptops (and netbooks and slates and tablets) are 'closed' devices. There's not a lot you can replace. Of course devices like this: http://www.linuxfordevices.com/c/a/News/Seagate-Momentus-XT/?kc=LNXDEVNL0526... are very attractive for laptops, slates and netbooks, especially at $150 for a 500G drive! -- Knowledge will forever govern ignorance: And a people who mean to be their own governours, must arm themselves with the power which knowledge gives. --James Madison, quoted on the Library of Congress -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Am 01.06.2010 13:53, schrieb Adam Tauno Williams:
On Tue, 2010-06-01 at 13:25 +0200, C wrote:
On Tue, Jun 1, 2010 at 12:58, Adam Tauno Williams wrote:
11.3. I've been doing some reading, and see a lot of conflicting info... in one place I see notes that you must set noatime and you cannot(should not)
"noatime" or a near work-alike [relatime?] is the default in modern kernels.
This is one of those conflicts of information I see. Some people say it's a default so no worries.. then the next says.. no way, you have to set this option or... the world will end... or your SSD will fail... whichever comes first.
The world will end - the question is just "when?" :)
There is no harm in using the noatime setting; I've been using noatime on all my production servers and my own laptop/workstation for years with no problem. No modern application cares about atime and it isn't even useful for auditing.
In large part because the hype has dyed down. SSDs offer some specific advantages in some cases; and none in most cases. Just a more expensive solution for [less] mass-storage. Unless you have a real I/O bottleneck problem - don't bother. Most of the people I've met who are using them are doing so because they are the cool-new-thing. There is that, but... on computers I've seen running on SSD drives, the boot cycle, and application startup is a LOT faster.
Really? I've seen demonstrations of that and not been impressed. You could get, IMNSHO, a bigger performance boost by spending that same amount of money on a lot more RAM. I've got spinning disks and 6GB of RAM and apps start pretty close to instantly. An order-of-magnitude difference I doubt would even be noticeable.
I also doubt that a normal user will notice any big difference, but there there is one case that makes me eager to try out ssd: hosting virtual machines on a ssd raid. Currently the number of VMs I can host on a server is limited by a) the amount of RAM b) the I/O of the storage device Just a few VMs on a SATA raid, and I already see noticable CPU Wait. SAS hdds make a huge difference already. SSD has many more IO operations per second, so it should perform much better for many concurrent IO operations than a spindle drive. Eventually even cached write operations have to be synched to the disk. So a storage kept busy by many VMs should really profit from a ssd. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 01 June 2010 13:53:30 Adam Tauno Williams wrote:
Really? I've seen demonstrations of that and not been impressed. You could get, IMNSHO, a bigger performance boost by spending that same amount of money on a lot more RAM.
This is not really true at all, not for anyone that already has enough RAM to avoid excessive swapping. You could have 64GB of RAM and your apps and boot will not be any faster because your still blocked on the bottleneck of your mechanical drives. You really need to use an SSD and then try to go back to using mechanical disks. The difference is very noticeable. From grub boot menu OS selection to fully loaded KDE4 desktop (with all the previous apps that were running in the last session) in under 10 seconds. There are some applications that even the fastest mechanical drives in the world (raptors) don't help with. Loading a workspace with a large source tree into an Eclipse IDE installation with a number of plugins is painfully slow from mechanical disks. Using an SSD in this case, and many others brings noticable and tangible real world benefits. Yes, they are still too damn expensive, but I could not work without them now. Using mechanical drives after using an SSD is rather like pulling out most of your RAM and heavily using swap. -- “What can be asserted without proof can be dismissed without proof.” - Christopher Hitchens -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 2010-06-02 at 06:09 +0200, Graham Anderson wrote:
On Tuesday 01 June 2010 13:53:30 Adam Tauno Williams wrote:
Really? I've seen demonstrations of that and not been impressed. You could get, IMNSHO, a bigger performance boost by spending that same amount of money on a lot more RAM.
This is not really true at all, not for anyone that already has enough RAM to avoid excessive swapping. You could have 64GB of RAM and your apps and boot will not be any faster because your still blocked on the bottleneck of your mechanical drives.
You really need to use an SSD and then try to go back to using mechanical disks. The difference is very noticeable. From grub boot menu OS selection to fully loaded KDE4 desktop (with all the previous apps that were running in the last session) in under 10 seconds.
Could be. I do a diskless openSUSE. So, the boot happens from RAM. I think so many other factors make the boot take longer. Like setting network devices with dhcp and mounting remote systems. Granted some of this is now moved to happen asynchronous to the initial boot login. But the hard disk seems, to me, to be one of many factors. And, for my use, not the one that makes the boot take longer. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Graham Anderson said the following on 06/02/2010 12:09 AM:
On Tuesday 01 June 2010 13:53:30 Adam Tauno Williams wrote:
Really? I've seen demonstrations of that and not been impressed. You could get, IMNSHO, a bigger performance boost by spending that same amount of money on a lot more RAM.
This is not really true at all, not for anyone that already has enough RAM to avoid excessive swapping. You could have 64GB of RAM and your apps and boot will not be any faster because your still blocked on the bottleneck of your mechanical drives.
Yes, it is true. You've done a switcheroo. You've focussed solely on booting. Swapping isn't only the reason to hit the disk. Starting new applications requires searching the directory trees and inodes, paging in blocks that weren't already in memory. Ditto opening files. Having more memory means these too can be 'cached' - or at least not paged out ONCE THEY ARE READ IN. As for booting ... how many times a year do you boot your server farm? I realise - and have stated - things are different for laptops (netbooks, slates, pads, smartphones). As I keep saying, Context Is Everything. Don't presume your context is the only one. -- `But that's ... completely ridiculous! ... [Y]ou could claim that *anything's* real if the only basis for believing in it is that nobody's *proved* it doesn't exist!' `Yes, you could,' said Xenophilius. `I am glad to see that you are opening your mind a little.' - `Harry Potter and the Deathly Hallows', J. K. Rowling -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 2010-06-02 at 06:46 -0400, Anton Aylward wrote:
Graham Anderson said the following on 06/02/2010 12:09 AM:
On Tuesday 01 June 2010 13:53:30 Adam Tauno Williams wrote:
Really? I've seen demonstrations of that and not been impressed. You could get, IMNSHO, a bigger performance boost by spending that same amount of money on a lot more RAM. This is not really true at all, not for anyone that already has enough RAM to avoid excessive swapping. You could have 64GB of RAM and your apps and boot will not be any faster because your still blocked on the bottleneck of your mechanical drives. Yes, it is true. You've done a switcheroo. You've focussed solely on booting. Swapping isn't only the reason to hit the disk.
+1
Starting new applications requires searching the directory trees and inodes, paging in blocks that weren't already in memory. Ditto opening files. Having more memory means these too can be 'cached' - or at least not paged out ONCE THEY ARE READ IN. As for booting ... how many times a year do you boot your server farm?
Or even your workstation or laptop? Once a day? And the way UNIX/LINUX manages shared libraries [they are shared! :)] that once you have the library in memory starting another application that uses that library is a simple initialization of another writable region for the libraries stack. The library doesn't get reloaded. Open OpenOffice. Close OpenOffice. Open it again. If you have sufficient memory [cached pages didn't get dropped] the second time you open it is *much* faster.
I realise - and have stated - things are different for laptops (netbooks, slates, pads, smartphones). As I keep saying, Context Is Everything. Don't presume your context is the only one.
--
Adam Tauno Williams
Adam Tauno Williams said the following on 06/02/2010 07:44 AM:
Open OpenOffice. Close OpenOffice. Open it again. If you have sufficient memory [cached pages didn't get dropped] the second time you open it is *much* faster.
Or better still ... Open OpenOffice. Close OpenOffice. Open Gimp. Edit some pictures. Leave gimp open. Open Firefox. Opps, you had 45 tabs with lots of graphics when you last shut it down. Let them all come up. Leave firefox open. Open KMail. No, not Thundrebird, it has some shared libraries with Firefox. You're running under Gnome, right? So Kmail has to drag in a lot of KDE libraries as well. Play some Windows based game. That requires starting up VMware and a virtual Windows. Suspend the game but don't shut it down. Go back to Kmail and start composing some mail using a external HTML editor. Don't shut that down either. Now open OpenOffice again. If it doesn't start up immediately because the shared libraries haven't been paged out then you don't have enough RAM. RAM is cheap. -- Don't join the book burners. Don't think you're going to conceal faults by concealing evidence that they ever existed. Don't be afraid to go in your library and read every book... Dwight D. Eisenhower -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 02 June 2010 12:46:56 Anton Aylward wrote:
Graham Anderson said the following on 06/02/2010 12:09 AM:
On Tuesday 01 June 2010 13:53:30 Adam Tauno Williams wrote:
Really? I've seen demonstrations of that and not been impressed. You could get, IMNSHO, a bigger performance boost by spending that same amount of money on a lot more RAM.
This is not really true at all, not for anyone that already has enough RAM to avoid excessive swapping. You could have 64GB of RAM and your apps and boot will not be any faster because your still blocked on the bottleneck of your mechanical drives.
Yes, it is true. You've done a switcheroo. You've focussed solely on booting.
No, I specifically mention "apps" as well.
Swapping isn't only the reason to hit the disk. Starting new applications requires searching the directory trees and inodes, paging in blocks that weren't already in memory. Ditto opening files. Having more memory means these too can be 'cached' - or at least not paged out ONCE THEY ARE READ IN.
And the first time you read the files when launching your app, pray tell exactly how having more RAM will help me here? Yes, context is everything ;) -- “What can be asserted without proof can be dismissed without proof.” - Christopher Hitchens -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Graham Anderson said the following on 06/04/2010 06:52 AM:
Swapping isn't only the reason to hit the disk. Starting new applications requires searching the directory trees and inodes, paging in blocks that weren't already in memory. Ditto opening files. Having more memory means these too can be 'cached' - or at least not paged out ONCE THEY ARE READ IN.
And the first time you read the files when launching your app, pray tell exactly how having more RAM will help me here?
Yes, context is everything ;)
I don't understand this obsession with booting. If my file system is already in RAM .... Years go, there were people (developers of course) who wrote to the magazines like Dr Dobbs going on about how slow compilers were. Or at last that they weren't fast enough. No attention was paid to the real issue which was how fast the resulting applications ran when they were in the hands to the end users. So, when I'm on the road I do actually turn my machine (laptop) off. In the morning I wake and stumble from my hotel bed and as I go past my desk I turn the laptop on. When I get back from the bathroom its booted. If it booted in 8 seconds or 8 minutes I'm not going to see the difference. If I'm at home my firewall and my mailhub/server are 'always on'. I have a friend who works for a company that sells SSD to major corporations. I've seen their sales presentation. It does not mention booting; it does not mention application start-up time. They pitch to database users. That is the context that big SSD is selling into. -- "The Air Force is reacting to the EPA ban on CFC's by replacing them in the cooling systems of the ICBMs. If they are ever fired, it will be an environmentally friendly nuclear holocaust, not threatening the Ozone layer." -- _Access to Energy_, July 1993 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 04 June 2010 13:11:25 Anton Aylward wrote:
I have a friend who works for a company that sells SSD to major corporations. I've seen their sales presentation. It does not mention booting; it does not mention application start-up time. They pitch to database users.
That is the context that big SSD is selling into.
Of course they would not pitch boot times to a server market. In the same light, do you pitch selling a consumer grade MLC based SSD by telling a home user how much of a performance gain he will get by storing his terabyte DB on a large SSD array? I touched on a context before in this thread where I receive significant gains in productivity and performance from using a consumer grade MLC based drive. I frequently swap between many eclipse workspaces that hold projects with large source trees. Having my workspaces and projects on an SSD gives me performance gains of an order of magnitude over HDD. Sure, having plenty of RAM has always been sensible but to equate holding in RAM the handful of dependent libraries that your browser uses, versus reading tens of thousands of source files is pointless. You don't buy an SSD so that firefox loads faster on the second time around. You buy an SSD so that everything loads fast, all the time. Something that no amount of RAM in the world will help you with. -- “What can be asserted without proof can be dismissed without proof.” - Christopher Hitchens -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, Jun 4, 2010 at 13:11, Anton Aylward wrote:
I don't understand this obsession with booting.
If my file system is already in RAM ....
It's one aspect. For a server.. it's not so interesting... for a desktop machine that is restarted into other OS installs it starts to be a factor. The key factor for me considering SSD drives on my main machine is/was to speed up general I/O. As Graham has pointed out, using an SSD so everything loads fast all the time (assuming you are using a good quality SSD with high throughput vs cheap ones with low data rates). Another consideration... RAM drive. If I've got.. say.. 16GB or more of system RAM.. what about pre-loading the entire OS into a RAMdrive... that could be.. interesting. Reminds me of the i-RAM http://en.wikipedia.org/wiki/I-RAM but I digress. On that note, I've been running my system with noatime now for a couple of days... the only difference I've seen (compared to the defaults from an 11.2 install on ReiserFS) is that OOo now takes forever to open the file dialogs to open/save as. I don't know if this is related to noatime or something else I've done (I'm a compulsive tinkerer so PEBKAC is entirely possible). C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 02 June 2010 02:43:01 Graham Anderson wrote:
You really need to use an SSD and then try to go back to using mechanical disks. The difference is _very_ noticeable. From grub boot menu OS selection to fully loaded KDE4 desktop (with all the previous apps that were running in the last session) in under 10 seconds.
Having read what I typed I couldn't help but think it was unrealistic and rather misleading about the time of under 10 seconds. I had measured this (very roughly) when I freshly installed M6 but that's not really a fair real world scenario, and it was an extremely minimal installation. I wondered if this still holds true now that I have been using the SSD for few weeks and my workstation installation is no longer freshly installed. Curious for answers I decided to perform some completely unscientific tests on my current workstation and setup. Hardware ----- Gigabyte P55 UD4 CPU/RAM: Intel i7 860 @ 3.5GHz, 8GB RAM @ 1600 (8-8-8-8-24) SSD: 2 x OCZ Vertex LE 100GB (non raid) HDD: 4 x Samsung F3 500GB, 7200 RPM (LVM + software raid) HDD: 1 x Samsung Spinpoint 250GB, 7200 RPM Partitioning/OS ------------ SSD1: /dev/sda1 /boot (200MB) /dev/sda2 swap (2GB) /dev/sda3 / (20GB, openSUSE 11.3 M7) /dev/sda4 extended /dev/sda5 / (20GB, openSUSE 11.2) SSD2: /dev/sdb1 /home (60GB) /dev/sdb2 /workspace (20GB, source, git repos, eclipse, OBS projects) HDD: /dev/sdc1 /boot (200MB) /dev/sdc2 /swap (4GB) /dev/sdc3 / (20GB, openSUSE 11.2, old setup) /dev/sdc4 NTFS (60GB Windows) LVM: /dev/vgData /data /dev/vgHome /home ( old home location for HDD sdc 11.2) /dev/vgBackup /snapshots (rsnapshot sets) Methodology ----------- Create new user and set automatic login for user to a KDE 4.4.3 desktop with konsole, dolphin and chromium applications running in the session, server daemons running at startup are httpd & mysqld. Booting 11.3, 11.2 from SSD with no mechanical HDD based partitions mounted at boot. Booting 11.2 from SSD with /home & /data mounted from mechanical disk based LVM. Booting 11.2 from mechanical HDD with /home & /data mounted from mechanical disk based LVM Boot each OS install 3 times, record the time from grub boot menu selection to fully loaded desktop. Launch eclipse, with -clean option to a busy workspace, record the time taken to launch application + plugins, then rebuild the workspace. Launch eclipse 3 times and average the result. Use an Identical Workspace with 7 projects open, 70k source/project files, first is stored on SSD, second is stored on HDD Results (timed with extremely accurate fingers and mobile phone stopwatch!) --------------------------------------------------------------------------- OS | Boot Time | ---------------------------------+--------------+ openSUSE 11.3 (SSD) | 15.8 seconds | openSUSE 11.2 (SSD) | 17.3 seconds | openSUSE 11.2 (SSD + HDD mounts) | 35.2 seconds | openSUSE 11.2 (HDD) | 58.5 seconds | Now these results really need to be taken at face value for what they are, and that is to say they are rather meaningless because I could not spend the time to ensure that the HDD based 11.2 system is loading the same kernel modules/daemons as the SSD based systems. Having said that, seeing as I am currently using the 11.3 M7 as my day to day OS. I can only think of the VirtualBox kernel module that would be loading on the HDD system and not the SSD systems. It should also be noted that the SSD based systems use tmpfs for /tmp Eclipse | Launch + Rebuild Workspace --------+--------------------------------- SSD | 24 seconds HDD | 3 minutes, 13 seconds This result on the other hand can taken rather more seriously. I can control the environment and make sure the workspace is identical, the eclipse version and plugins are identical, using the same version of JVM. If I have some spare time, and can be bothered, I may follow this up with a kernel compile. Feel free to draw your own conclusions and flame away for being completely pointless and unscientific benchmarks ;) Cheers the noo, Graham -- “What can be asserted without proof can be dismissed without proof.” - Christopher Hitchens -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
El 31/05/10 11:51, C escribió:
Has anyone started seriously testing and tinkering with openSUSE on SSD drives?
- Use the BTRFS filesystem - boot your kernel with elevator=noop - mount your filesystems "noatime" -- ?? -- profit. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, Jun 1, 2010 at 2:56 PM, Cristian Rodríguez
El 31/05/10 11:51, C escribió:
Has anyone started seriously testing and tinkering with openSUSE on SSD drives?
- Use the BTRFS filesystem - boot your kernel with elevator=noop - mount your filesystems "noatime" -- ?? -- profit.
Cristian, Mounting with relatime has been the Linux kernel and Opensuse default for a year or more. Why do you think noatime will significantly improve on relatime? Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retriev... The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Am Dienstag, 1. Juni 2010 schrieb Greg Freemyer:
[...]. Mounting with relatime has been the Linux kernel and Opensuse default for a year or more.
I thought, laptop-mode-tools added this option for me.
Why do you think noatime will significantly improve on relatime?
http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/ | Unfortunately, relatime is not free. As you can see below, it has roughly | double the overhead of noatime (but roughly half the overhead of using the | standard Posix atime semantics): Gruß Jan -- The hidden flaw never remains hidden. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, Jun 1, 2010 at 3:59 PM, Jan Ritzerfeld
Am Dienstag, 1. Juni 2010 schrieb Greg Freemyer:
[...]. Mounting with relatime has been the Linux kernel and Opensuse default for a year or more.
I thought, laptop-mode-tools added this option for me.
No its a generic kernel thing I believe since 2.6.27 or so (ie. since OS 11.1). So if you call mount with no options, you now get "relatime" as I understand it. And Ted's post you linked to says Mutt breaks if you simply switch to noatime without in some way reconfiguring Mutt. (He doesn't provide details as to how to fix Mutt.) So, switching to noatime is not a zero risk proposition, especially for the entire distro.
Why do you think noatime will significantly improve on relatime?
http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/ | Unfortunately, relatime is not free. As you can see below, it has roughly | double the overhead of noatime (but roughly half the overhead of using the | standard Posix atime semantics):
Yes, but his conclusion includes: === the problem was that first generation SSD’s had a very bad problem with what has been called the “write amplification effect”, where a 4k write might cause a 128k region of the SSD to be erased and rewritten. ... However, the next generation of SSD’s, such as Intel’s X25-M SSD, have worked around the write amplification affect. === I personally think the first generation devices are just too slow to be considered a performance boost for lots of reasons, so I will not be buying one period. As to the second generation devices which have been around for 18 months now I believe, they are much faster than rotating disk at random i/o (Approx 15K io's / second), so using noatime with them is much less of a boost than for rotating disk. So if your not using noatime for rotating, why would you suddenly consider it critical for SSD. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hello, On Tue, 01 Jun 2010, Greg Freemyer wrote:
And Ted's post you linked to says Mutt breaks if you simply switch to noatime without in some way reconfiguring Mutt. (He doesn't provide details as to how to fix Mutt.)
==== mutt/manual.txt ==== Note: new mail is detected by comparing the last modification time to the last access time. Utilities like biff or frm or any other program which accesses the mailbox might cause Mutt to never detect new mail for that mailbox if they do not properly reset the access time. Backup tools are another common reason for updated access times. ====
As to the second generation devices which have been around for 18 months now I believe, they are much faster than rotating disk at random i/o (Approx 15K io's / second), so using noatime with them is much less of a boost than for rotating disk.
The magazine c't (http://ct.de) from 2010/05/25 has tested new SSDs. The Crucial CTFDDAC256MAG-1G1 RealSSD reaches seq. reads of 257/322 (min/max) MB/s w/64K blocks, writes 95/221 MB/s and 39300/59755 IO/s write/read. Intel X25-M G2 172/241, 28/85, 7712/40433. Oh, and BTW: SSDs use 512K blocks, if you modify a 4k block in the FS, the SSD neads to read, modify write that block. If now the 8 512B sectors of a 4k FS-Block span two 512K SSD blocks, the SSD needs to read, modify, write two such blocks ... So, aligning the FS is important. HTH, -dnh -- I don't see anything wrong with being arrogant and not at all helpful. -- Paul Tomblin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, 2010-06-03 at 00:54 +0200, David Haller wrote:
Hello,
On Tue, 01 Jun 2010, Greg Freemyer wrote:
And Ted's post you linked to says Mutt breaks if you simply switch to noatime without in some way reconfiguring Mutt. (He doesn't provide details as to how to fix Mutt.)
==== mutt/manual.txt ==== Note: new mail is detected by comparing the last modification time to the last access time. Utilities like biff or frm or any other program which accesses the mailbox might cause Mutt to never detect new mail for that mailbox if they do not properly reset the access time. Backup tools are another common reason for updated access times. ====
Odd. access != modification. Backup should only care about changes, not simple accesses that do not change the thing accessed. I wonder if the docs match the program. Perhaps what they mean by access is modification, and are just being imprecise in the description. I would be sorely disappointed in any software that detected changes because I had looked at - but not changed - something. I wonder about the mutt method. If an independent program that had nothing to do with showing me mail accessed (no change) a mail message file before mutt did, mutt would not detect that it was new? Or does mutt also say that no other software can look at (not change) the mail files? -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Roger Oberholtzer
On Thu, 2010-06-03 at 00:54 +0200, David Haller wrote:
==== mutt/manual.txt ==== Note: new mail is detected by comparing the last modification time to the last access time. Utilities like biff or frm or any other program which accesses the mailbox might cause Mutt to never detect new mail for that mailbox if they do not properly reset the access time. Backup tools are another common reason for updated access times. ====
Odd. access != modification.
But it does :^). It changes the access time and shows that the mail is now "old" rather than "new". old != unread & unread != new
Backup should only care about changes, not simple accesses that do not change the thing accessed. I wonder if the docs match the program. Perhaps what they mean by access is modification, and are just being imprecise in the description. I would be sorely disappointed in any software that detected changes because I had looked at - but not changed - something.
re mutt, backup has nothing to do with mutt.
I wonder about the mutt method. If an independent program that had nothing to do with showing me mail accessed (no change) a mail message file before mutt did, mutt would not detect that it was new? Or does mutt also say that no other software can look at (not change) the mail files?
But there *is* a change between a file "never accessed" and one that has been accessed. Mutt uses this distinction. -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, 2010-06-03 at 10:25 -0400, Patrick Shanahan wrote:
But there *is* a change between a file "never accessed" and one that has been accessed. Mutt uses this distinction.
How does this work?: 1. mutt is not running. I have gone home. 2. A new message arrives. 3. My backup program backs up my e-mail. In doing do it accesses the file. Or some silly accounting script counts the number of files I have on the system. No matter. The file is accessed for whatever nefarious reason. 4. I arrive back at work and start mutt. The access time on the file will be newer than the modification time. Will mutt tell me the message is new? The description suggests that mutt will not see the new messages. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Roger Oberholtzer
On Thu, 2010-06-03 at 10:25 -0400, Patrick Shanahan wrote:
But there *is* a change between a file "never accessed" and one that has been accessed. Mutt uses this distinction.
How does this work?:
1. mutt is not running. I have gone home.
2. A new message arrives.
3. My backup program backs up my e-mail. In doing do it accesses the file. Or some silly accounting script counts the number of files I have on the system. No matter. The file is accessed for whatever nefarious reason.
4. I arrive back at work and start mutt.
The access time on the file will be newer than the modification time. Will mutt tell me the message is new?
No, access time has been altered, mail is "old" but unread.
The description suggests that mutt will not see the new messages.
Mutt "sees" the msg but it is *not* "new", access time has changed. -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, 2010-06-03 at 14:52 -0400, Patrick Shanahan wrote:
* Roger Oberholtzer
[06-03-10 10:47]: On Thu, 2010-06-03 at 10:25 -0400, Patrick Shanahan wrote:
But there *is* a change between a file "never accessed" and one that has been accessed. Mutt uses this distinction.
How does this work?:
1. mutt is not running. I have gone home.
2. A new message arrives.
3. My backup program backs up my e-mail. In doing do it accesses the file. Or some silly accounting script counts the number of files I have on the system. No matter. The file is accessed for whatever nefarious reason.
4. I arrive back at work and start mutt.
The access time on the file will be newer than the modification time. Will mutt tell me the message is new?
No, access time has been altered, mail is "old" but unread.
The description suggests that mutt will not see the new messages.
Mutt "sees" the msg but it is *not* "new", access time has changed.
Exactly as I thought. So mutt is not doing this in the most robust manner. Because from the mail reading pov, the message is indeed new. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Roger Oberholtzer
On Thu, 2010-06-03 at 14:52 -0400, Patrick Shanahan wrote:
Mutt "sees" the msg but it is *not* "new", access time has changed.
Exactly as I thought. So mutt is not doing this in the most robust manner. Because from the mail reading pov, the message is indeed new.
Indeed, the mail is unread but also not "new". It *has* been accessed. The system has no way to indicate that the access was by the intended reader, your neighbor, the cat or another program. Computers are not yet that "intelligent". But you are "picking hairs". Mutt has performed in this manner for many years and that manner has been acceptable to its users. -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 5 Jun 2010 00:18:06 Patrick Shanahan wrote:
* Roger Oberholtzer
[06-04-10 02:43]: On Thu, 2010-06-03 at 14:52 -0400, Patrick Shanahan wrote:
Mutt "sees" the msg but it is *not* "new", access time has changed.
Exactly as I thought. So mutt is not doing this in the most robust manner. Because from the mail reading pov, the message is indeed new.
Indeed, the mail is unread but also not "new". It *has* been accessed. The system has no way to indicate that the access was by the intended reader, your neighbor, the cat or another program. Computers are not yet that "intelligent". But you are "picking hairs". Mutt has performed in this manner for many years and that manner has been acceptable to its users.
I haven't been following this thread since its beginning, but can you not mount the directory containing the mail store with the noatime option? This does not update the access time every time the file is accessed by some process - it only updates the last modified time when mods are actually written to the file (it also slightly speeds up performance and reduces the number of disk writes, which could be important on SSD). -- =================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au =================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, Jun 4, 2010 at 11:09 AM, Rodney Baker
On Sat, 5 Jun 2010 00:18:06 Patrick Shanahan wrote:
* Roger Oberholtzer
[06-04-10 02:43]: On Thu, 2010-06-03 at 14:52 -0400, Patrick Shanahan wrote:
Mutt "sees" the msg but it is *not* "new", access time has changed.
Exactly as I thought. So mutt is not doing this in the most robust manner. Because from the mail reading pov, the message is indeed new.
Indeed, the mail is unread but also not "new". It *has* been accessed. The system has no way to indicate that the access was by the intended reader, your neighbor, the cat or another program. Computers are not yet that "intelligent". But you are "picking hairs". Mutt has performed in this manner for many years and that manner has been acceptable to its users.
I haven't been following this thread since its beginning, but can you not mount the directory containing the mail store with the noatime option? This does not update the access time every time the file is accessed by some process - it only updates the last modified time when mods are actually written to the file (it also slightly speeds up performance and reduces the number of disk writes, which could be important on SSD).
Rodney, You have it backwards. noatime is what breaks a mutt install with default config because it depends on atime being updated when a email is read. Totally unrelated to noatime, the atime issue highlights that lots of tools break Mutt's assumption that atime newer than mtime means a file has been read. But that broken assumption is a legacy problem the Mutt appears to have always had and it seems there are non-default config options that allow Mutt to quit using atime as a key flagging field. As yet I haven't seen any discussion of the work-around. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 5 Jun 2010 01:08:11 Greg Freemyer wrote:
On Fri, Jun 4, 2010 at 11:09 AM, Rodney Baker
wrote: On Sat, 5 Jun 2010 00:18:06 Patrick Shanahan wrote:
* Roger Oberholtzer
[06-04-10 02:43]: On Thu, 2010-06-03 at 14:52 -0400, Patrick Shanahan wrote:
Mutt "sees" the msg but it is *not* "new", access time has changed.
Exactly as I thought. So mutt is not doing this in the most robust manner. Because from the mail reading pov, the message is indeed new.
Indeed, the mail is unread but also not "new". It *has* been accessed. The system has no way to indicate that the access was by the intended reader, your neighbor, the cat or another program. Computers are not yet that "intelligent". But you are "picking hairs". Mutt has performed in this manner for many years and that manner has been acceptable to its users.
I haven't been following this thread since its beginning, but can you not mount the directory containing the mail store with the noatime option? This does not update the access time every time the file is accessed by some process - it only updates the last modified time when mods are actually written to the file (it also slightly speeds up performance and reduces the number of disk writes, which could be important on SSD).
Rodney,
You have it backwards.
noatime is what breaks a mutt install with default config because it depends on atime being updated when a email is read.
Totally unrelated to noatime, the atime issue highlights that lots of tools break Mutt's assumption that atime newer than mtime means a file has been read.
But that broken assumption is a legacy problem the Mutt appears to have always had and it seems there are non-default config options that allow Mutt to quit using atime as a key flagging field. As yet I haven't seen any discussion of the work-around.
Greg
OK, thanks for the explanation. It makes sense now. -- =================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au =================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Greg Freemyer
noatime is what breaks a mutt install with default config because it depends on atime being updated when a email is read.
Totally unrelated to noatime, the atime issue highlights that lots of tools break Mutt's assumption that atime newer than mtime means a file has been read.
But that broken assumption is a legacy problem the Mutt appears to have always had and it seems there are non-default config options that allow Mutt to quit using atime as a key flagging field. As yet I haven't seen any discussion of the work-around.
from: http://wiki.mutt.org/?MuttFaq/Folder <quote> Why are "new" flags of mbox folders wrong in folder-list view? As written in manual.txt, the flags are determined by comparing the timestamps of last access and modification. This can get messed up if the folders are "touched" by other programs than mutt, like "biff" or backup software. There is also some issue with the "noatime" flag for mounting filesystems (most often used on laptops). If "noatime" is activated, no timestamp is updated for the last folder access, i.e. Mutt cannot determine if the folder has received new mail since last visited. For mutt before version 1.5.15, you can recompile it with the --enable-buffy-size option to "configure"; for mutt 1.5.15 or later see the $check_mbox_size option. Mutt will then use the folder size instead of the access times. (This is only a workaround and might give suboptimal results; another option is to use the MaildirFormat.) </quote> and from: http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/ssd%E2%80%99s... <quote> Personally, I don’t think relatime is worth it. There are other ways of working around the issue with mutt — for example, you can use Maildir-style mailboxes, or you can use mutt’s check_mbox_size option. If the goal is to reduce unnecessary disk writes, I would mount my file systems using noatime, and use other workarounds as necessary. Alternatively, you can use chattr +A to set the noatime flag on all files and directories where you don’t want noatime semantics, and then clear the flag for the Unix mbox files where you care about the atime updates. Since the noatime flag is inherited by default, you can get this behaviour by setting running chattr +A /mntpt right after the filesystem is first created and mounted; all files and directories created in that file system will have the noatime file inherited. </quote> -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2010-06-04 at 10:48 -0400, Patrick Shanahan wrote:
* Roger Oberholtzer
[06-04-10 02:43]: On Thu, 2010-06-03 at 14:52 -0400, Patrick Shanahan wrote:
Mutt "sees" the msg but it is *not* "new", access time has changed.
Exactly as I thought. So mutt is not doing this in the most robust manner. Because from the mail reading pov, the message is indeed new.
Indeed, the mail is unread but also not "new". It *has* been accessed. The system has no way to indicate that the access was by the intended reader, your neighbor, the cat or another program. Computers are not yet that "intelligent". But you are "picking hairs". Mutt has performed in this manner for many years and that manner has been acceptable to its users.
I agree that people have used mutt with this crappy design feature, and most will continue to use it with no problems. But programmers do indeed have more "intelligent" ways to tell that a specific program has been the one to read a file. Computers are indeed "intelligent" enough to handle this logic - if programmers are "intelligent" enough to tell them to do so! IMAP does it all the time. I would suggest that folk who want to tweak that last bit of 'performance' from their file system(1) remove noatime to speed up the file system (2) drop mutt until it fixes it's rather incorrect method of determining if mutt has accessed a file. Of course, that won't happen. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
El 01/06/10 17:37, Greg Freemyer escribió:
And Ted's post you linked to says Mutt breaks if you simply switch to noatime without in some way reconfiguring Mutt. (He doesn't provide details as to how to fix Mutt.)
There are multiple ways to fix mutt configuration (and Btw, I doubt the "average Joe user" is running mutt as mail client ) If mutt were able to use inotify instead, it would be better ;) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Cristian Rodríguez
El 01/06/10 17:37, Greg Freemyer escribió:
And Ted's post you linked to says Mutt breaks if you simply switch to noatime without in some way reconfiguring Mutt. (He doesn't provide details as to how to fix Mutt.)
There are multiple ways to fix mutt configuration (and Btw, I doubt the "average Joe user" is running mutt as mail client )
As "average Joe user" is definitely not what it was before the influx of gui users, this is a true statement. Mutt appeals more to those who want "control" of their reader. Mutt is a *text* mail reader, not a "web page" reader, and as such appeals more to keyboard users than gui/mouse-click-click users. Remember when the mouse was just for games?
If mutt were able to use inotify instead, it would be better ;)
possibly, depending on individual situations. -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (15)
-
Adam Tauno Williams
-
Anton Aylward
-
Brian K. White
-
C
-
Cristian Rodríguez
-
David Haller
-
Graham Anderson
-
Greg Freemyer
-
Hans Witvliet
-
Jan Ritzerfeld
-
Patrick Shanahan
-
Per Jessen
-
Rodney Baker
-
Roger Oberholtzer
-
Sandy Drobic