FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 05-13-2011, 09:21 PM
Paul E Condon
 
Default Tracing Filesystem Accesses

On 20110513_220818, Jochen Schulz wrote:
> Bob McConnell:
> >
> > Before we go any further, lets get a couple of things sorted out.
> > What type of SSD (Solid State Drive) are you all talking about here?
> >
> > If it contains Flash memory,
>
> What else do you have in mind?
>
> > then yes, there is a limit to the
> > number of ERASE cycles each sector can do. How long they last
> > depends on a number of factors, not the least of which is how old
> > the chips are. The first generations of flash memory chips could
> > only be erased about 10,000 times before they started to fail.
>
> Current generation (consumer-grade) MLC SSDs using 25nm technology use
> flash that can only be rewritten 3000 times. Assuming perfect wear
> levelling, that's still enough for most desktop applications.
> 120GB*3000=360TB. That's still almost 100GB per day for ten years. Even
> if write amplification quintuples the amount of date written, that's
> still 20GB per day. My systems don't write that much.

This seems like hi-jacking my sub-thread. I asked a question of Stan
Hoeppner because I was puzzled about the status of the technology
behind the techy-buzzword SSD. The unstated purpose of asking was to
get some clarity, for me, as to what he was talking about. I don't
want to be the cause of a outburst of name calling. Has there been a
major advance that obsoletes old conventional wisdom? It might be. I
don't know. And editing out things that are irrelevant to ones comment
certainly muddles the context. An example of how e-list rules really
just exacerbate a complex issue.

By the way, what is MLC in this context?

--
Paul E Condon
pecondon@mesanetworks.net


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110513212128.GA3216@big.lan.gnu">http://lists.debian.org/20110513212128.GA3216@big.lan.gnu
 
Old 05-13-2011, 11:55 PM
Stan Hoeppner
 
Default Tracing Filesystem Accesses

On 5/13/2011 1:34 PM, Bob McConnell wrote:

> Before we go any further, lets get a couple of things sorted out. What
> type of SSD (Solid State Drive) are you all talking about here?
>
> If it contains Flash memory, then yes, there is a limit to the number of
> ERASE cycles each sector can do. How long they last depends on a number
> of factors, not the least of which is how old the chips are. The first
> generations of flash memory chips could only be erased about 10,000
> times before they started to fail. This could be mitigated by decent
> firmware that did load leveling behind the scenes. But there was still a
> finite limit to how long they could be used before they wouldn't erase
> anymore. Newer chips can handle 100,000-250,000 erase cycles. So decent
> drivers can help them last for several years even under heavy use. If
> the wear is spread out over a large space, it almost appears to last
> forever. But I still wouldn't want to use them for files that were
> frequently replaced or rewritten. I still think of them as Read-Mostly
> memory components.

Apparently no one is reading the authoritative article I cited.

Modern SSDs are definitely not limited to use as "Read-Mostly" devices.
Mail spools are write mostly directories. There are many high volume
mail sites using SSDs for their mail spools due to the massive random
write IOPS capability and cost savings when compared to striping many
SRDs together.

A single quality SSD can easily sustain 20k+ random write IOPS. To
achieve 20k random write IOPS with SRDs would require 132 7.2k SATA
drives. As SMTP mail is totally disk IO bound and requires almost no
CPU, building out a massive cluster of cheap 1 CPU nodes in an MX farm
with only a single spindle of IOPS per node wastes a ton of money in
completely under utilized processor/memory/power/etc. This is what many
ISPs previously did to avoid buying expensive SAN storage to achieve the
required aggregate spool IOPS.

Today they can eliminate 130 of those nodes and replace the SRDs in two
or 4 of them with SSDs, achieving the same or better performance with
only 2 or 4 MX nodes. Not only have they saved $60-100k on node costs
but they just eliminated the need for 130 switch ports as well, approx
$25k, and rack space, 4U vs 132U. And they save tens of thousands of
dollars per year on electricity by eliminating 128 nodes.

The cost of the appropriate SSDs is less than $4k. SSDs today are
definitely not "Read-Mostly" devices.

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DCDC4EB.1060207@hardwarefreak.com">http://lists.debian.org/4DCDC4EB.1060207@hardwarefreak.com
 
Old 05-14-2011, 12:27 AM
Stan Hoeppner
 
Default Tracing Filesystem Accesses

On 5/13/2011 4:21 PM, Paul E Condon wrote:

> This seems like hi-jacking my sub-thread. I asked a question of Stan
> Hoeppner because I was puzzled about the status of the technology
> behind the techy-buzzword SSD. The unstated purpose of asking was to
> get some clarity, for me, as to what he was talking about. I don't
> want to be the cause of a outburst of name calling. Has there been a
> major advance that obsoletes old conventional wisdom? It might be. I
> don't know. And editing out things that are irrelevant to ones comment
> certainly muddles the context. An example of how e-list rules really
> just exacerbate a complex issue.

Paul, the questions are you asking were most/all answered in detail in
the article I cited, or via simple Google searches. The question
directly below tells us you haven't read it, or anything at all about
SSDs, which means we can't have a decent discussion of the technology
without wasting thousands of typed characters bringing you up to speed,
in a totally OT thread no less.

> By the way, what is MLC in this context?

http://lmgtfy.com/?q=mlc

With all due respect and no intention to hurt your feelings Paul, if you
don't already know what MLC, SLC, NAND, wear leveling, TRIM, etc are,
please duck out of this discussion until you've brought yourself up to
speed on SSD basics. You're not being fair to yourself or this list
with your participation, simply adding more useless noise to an already
noisy OT thread.

The reason we're discussing SSD life span is lack of sufficient
authoritative/independent industry documentation on the subject, and FUD
resulting from that void. There is a plethora of SSD basics
documentation available.

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DCDCC7F.8080905@hardwarefreak.com">http://lists.debian.org/4DCDCC7F.8080905@hardwarefreak.com
 
Old 05-14-2011, 04:06 AM
Paul E Condon
 
Default Tracing Filesystem Accesses

On 20110513_192743, Stan Hoeppner wrote:
> On 5/13/2011 4:21 PM, Paul E Condon wrote:
>
> > This seems like hi-jacking my sub-thread. I asked a question of Stan
> > Hoeppner because I was puzzled about the status of the technology
> > behind the techy-buzzword SSD. The unstated purpose of asking was to
> > get some clarity, for me, as to what he was talking about. I don't
> > want to be the cause of a outburst of name calling. Has there been a
> > major advance that obsoletes old conventional wisdom? It might be. I
> > don't know. And editing out things that are irrelevant to ones comment
> > certainly muddles the context. An example of how e-list rules really
> > just exacerbate a complex issue.
>
> Paul, the questions are you asking were most/all answered in detail in
> the article I cited, or via simple Google searches. The question
> directly below tells us you haven't read it, or anything at all about
> SSDs, which means we can't have a decent discussion of the technology
> without wasting thousands of typed characters bringing you up to speed,
> in a totally OT thread no less.
>
> > By the way, what is MLC in this context?
>
> http://lmgtfy.com/?q=mlc
>
> With all due respect and no intention to hurt your feelings Paul, if you
> don't already know what MLC, SLC, NAND, wear leveling, TRIM, etc are,
> please duck out of this discussion until you've brought yourself up to
> speed on SSD basics. You're not being fair to yourself or this list
> with your participation, simply adding more useless noise to an already
> noisy OT thread.
>
> The reason we're discussing SSD life span is lack of sufficient
> authoritative/independent industry documentation on the subject, and FUD
> resulting from that void. There is a plethora of SSD basics
> documentation available.

As you say the thread is a bit OT. I mostly kept deleting new posts to
it, but then I read a few while waiting for a response to one of my
questions. I started with question, 'Why is this going on so long?' I
think I did learn something interesting about SSD, maybe even some day
useful to me. I rather like reading about things I know nothing about.

Thanks.

--
Paul E Condon
pecondon@mesanetworks.net


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110514040642.GC3216@big.lan.gnu">http://lists.debian.org/20110514040642.GC3216@big.lan.gnu
 
Old 05-14-2011, 04:02 PM
Rainer Dorsch
 
Default Tracing Filesystem Accesses

Am Freitag, 13. Mai 2011 schrieb Miles Fidelman:
> Stan Hoeppner wrote:
> > On 5/12/2011 5:19 AM, Rainer Dorsch wrote:
> >> Hello,
> >>
> >> I added an SSD in my system and moved the root filesystem to the SSD
> >> (which
> >> includes now also most of /home in my system). I spin down the
> >> regular hard
> >> disks and the system is a lot more quiet than before :-)
> >>
> >> Sometimes though something is accessing data on the disk drives,
> >> which I do
> >> not understand.
> >
> > Did you relocate swap to the SSD?
>
> What do you have under root vs. your hard drives. There's lots of stuff
> going on all the time - network activity, mail spools, cron jobs, logging.

To answer a few questions:

- I did not relocate swap to SSD, but reduce swapiness:
echo 20 > /proc/sys/vm/swappiness
I have 4 GB or RAM, in most cases that is more than plenty for me. As long
as top shows 0 swap in use, I would think I am safe.

My Main reason for not doing it was that I do run the SSD partitionless to
avoid partition alignment issues.

- I moved everything on the SSD except some folders in /opt and /home

- I tried lsof before, but this did not help, I assume I was too slow.

- The inotifywait works nicely :-)

Thanks,
Rainer

--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdorsch@web.de
jabber: rdorsch@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/
 
Old 05-14-2011, 06:16 PM
Stan Hoeppner
 
Default Tracing Filesystem Accesses

On 5/14/2011 11:02 AM, Rainer Dorsch wrote:
> Am Freitag, 13. Mai 2011 schrieb Miles Fidelman:
>> Stan Hoeppner wrote:
>>> On 5/12/2011 5:19 AM, Rainer Dorsch wrote:

>>>> Sometimes though something is accessing data on the disk drives,
>>>> which I do
>>>> not understand.

>>> Did you relocate swap to the SSD?
>>
>> What do you have under root vs. your hard drives. There's lots of stuff
>> going on all the time - network activity, mail spools, cron jobs, logging.
>
> To answer a few questions:
>
> - I did not relocate swap to SSD, but reduce swapiness:
> echo 20 > /proc/sys/vm/swappiness
> I have 4 GB or RAM, in most cases that is more than plenty for me. As long
> as top shows 0 swap in use, I would think I am safe.

Safe for now.

> My Main reason for not doing it was that I do run the SSD partitionless to
> avoid partition alignment issues.

There are no partition alignment issues with SSDs. SSDs have no
cylinders, no heads, no mechanical parts. Native sector size is 512B,
access time to every sector on the device is uniform--non issue. SSD
random read/write access is 10,000x faster than your HDDs so make a
small swap file on the SSD--you don't need a partition for swap, use a
file. It's brain dead simple. Make a 128MB swap file just so you have
some swap to keep the kernel happy. BTW, it is possible to run totally
without swap. You just might see some unintended consequences doing so.
With 4GB RAM on a workstation it's unlikely though. Anyway, to
deactivate and remove the current swap partition, and make a small 128MB
swap file on your SSD and activate it:

# swappoff -a
# dd if=/dev/zero of=/swapfile1 bs=1024 count=131072
# mkswap /swapfile1
# swapon /swapfile1
# vi /etc/fstab
Add:
/swapfile1 swap swap defaults 0 0

and remove the old swap entry. On reboot only new swap file is used.
Linux has had swap file capability for many years, introduced in 2.6.

The kernel keeps track of the on disk location of swap files and
bypasses the filesystem and buffer cache, performing direct disk access.
With modern hardware, whether SSD or hard disk, there is no performance
difference between a swap file or partition. Using swap files simply
gives you more flexibility--you can add or remove swap anywhere, any
time, without needing to dedicate partitions to swap.

> - I moved everything on the SSD except some folders in /opt and /home

Why haven't you moved those over?

> - The inotifywait works nicely :-)

So tell us what is accessing the disks already. Lemme guess, some cron
job firing a binary in /opt.

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DCEC70C.9020803@hardwarefreak.com">http://lists.debian.org/4DCEC70C.9020803@hardwarefreak.com
 
Old 05-15-2011, 09:21 AM
"Boyd Stephen Smith Jr."
 
Default Tracing Filesystem Accesses

In <4DCEC70C.9020803@hardwarefreak.com>, Stan Hoeppner wrote:
>On 5/14/2011 11:02 AM, Rainer Dorsch wrote:
>> My Main reason for not doing it was that I do run the SSD partitionless
>> to avoid partition alignment issues.
>
>There are no partition alignment issues with SSDs. SSDs have no
>cylinders, no heads, no mechanical parts. Native sector size is 512B,
>access time to every sector on the device is uniform--non issue.

SSDs do benefit slightly from having partitions aligned with pages or blocks.
Those pages are generally somewhere between 4KiB and 64KiB in size. Blocks
are larger, some getting up to 8MiB. <http://www.anandtech.com/show/2738/5>
and <http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux> seem to
be decent references.

Traditionally, being unable to TRIM has caused reduced performance over time
on SSDs. However, SSDs have such a performance increase over SMDs that I
doubt misalignment would be noticed very much.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
 
Old 05-15-2011, 09:03 PM
Rainer Dorsch
 
Default Tracing Filesystem Accesses

Am Samstag, 14. Mai 2011 schrieb Stan Hoeppner:
> On 5/14/2011 11:02 AM, Rainer Dorsch wrote:
> > Am Freitag, 13. Mai 2011 schrieb Miles Fidelman:
> >> Stan Hoeppner wrote:
> >>> On 5/12/2011 5:19 AM, Rainer Dorsch wrote:
> >>>> Sometimes though something is accessing data on the disk drives,
> >>>> which I do
> >>>> not understand.
> >>>
> >>> Did you relocate swap to the SSD?
> >>
> >> What do you have under root vs. your hard drives. There's lots of stuff
> >> going on all the time - network activity, mail spools, cron jobs,
> >> logging.
> >
> > To answer a few questions:
> >
> > - I did not relocate swap to SSD, but reduce swapiness:
> > echo 20 > /proc/sys/vm/swappiness
> > I have 4 GB or RAM, in most cases that is more than plenty for me. As
> > long as top shows 0 swap in use, I would think I am safe.
>
> Safe for now.
>
> > My Main reason for not doing it was that I do run the SSD partitionless
> > to avoid partition alignment issues.
>
> There are no partition alignment issues with SSDs. SSDs have no

I can report differently:

I see between 5% and 100% better dd write performance when running
partitionless compared to my original (50GB/70GB) partioning:

blackbox:~# fdisk -ul /dev/sdc

Disk /dev/sdc: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdc1 * 63 97659134 48829536 83 Linux
/dev/sdc2 97659135 234436544 68388705 83 Linux
blackbox:~#

(that is what cfdisk created without taking any special care).

For small write blocks the performance improvement is higher.

Here is a lengthy blog from Ted Tso on that topic (be warned, it was not an
easy read for me):
http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd’s-erase-
block-size

> cylinders, no heads, no mechanical parts. Native sector size is 512B,
> access time to every sector on the device is uniform--non issue. SSD
> random read/write access is 10,000x faster than your HDDs so make a
> small swap file on the SSD--you don't need a partition for swap, use a
> file. It's brain dead simple. Make a 128MB swap file just so you have
> some swap to keep the kernel happy. BTW, it is possible to run totally
> without swap. You just might see some unintended consequences doing so.
> With 4GB RAM on a workstation it's unlikely though. Anyway, to
> deactivate and remove the current swap partition, and make a small 128MB
> swap file on your SSD and activate it:
>
> # swappoff -a
> # dd if=/dev/zero of=/swapfile1 bs=1024 count=131072
> # mkswap /swapfile1
> # swapon /swapfile1
> # vi /etc/fstab
> Add:
> /swapfile1 swap swap defaults 0 0
>
> and remove the old swap entry. On reboot only new swap file is used.
> Linux has had swap file capability for many years, introduced in 2.6.
>
> The kernel keeps track of the on disk location of swap files and
> bypasses the filesystem and buffer cache, performing direct disk access.
> With modern hardware, whether SSD or hard disk, there is no performance
> difference between a swap file or partition. Using swap files simply
> gives you more flexibility--you can add or remove swap anywhere, any
> time, without needing to dedicate partitions to swap.

Thank you for the detailed instructions. The biggest pain of having swap for
me is that the harddist needs to start during shutdown and I think during
startup it tries to resume from this partition.

I thought of putting the swap partition on an USB stick (almost never used in
my system and it should be faster than starting a disk during shutdown).

> > - I moved everything on the SSD except some folders in /opt and /home
>
> Why haven't you moved those over?

The SSD is too small to put everything on it (e.g. photo/video collection).

> > - The inotifywait works nicely :-)
>
> So tell us what is accessing the disks already. Lemme guess, some cron
> job firing a binary in /opt.

I still need to track that down in detail, once I saw backup running. My
biggest suspect right now is nepomuk, I will report when I can confirm it.

Rainer

--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdorsch@web.de
jabber: rdorsch@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/
 
Old 05-16-2011, 11:30 AM
Stan Hoeppner
 
Default Tracing Filesystem Accesses

On 5/15/2011 4:21 AM, Boyd Stephen Smith Jr. wrote:
> In <4DCEC70C.9020803@hardwarefreak.com>, Stan Hoeppner wrote:
>> On 5/14/2011 11:02 AM, Rainer Dorsch wrote:
>>> My Main reason for not doing it was that I do run the SSD partitionless
>>> to avoid partition alignment issues.
>>
>> There are no partition alignment issues with SSDs. SSDs have no
>> cylinders, no heads, no mechanical parts. Native sector size is 512B,
>> access time to every sector on the device is uniform--non issue.
>
> SSDs do benefit slightly from having partitions aligned with pages or blocks.

Do you have some test results, or a link, showing the performance
difference between aligned and non-aligned current generation SSDs, to
back this claim?

> Those pages are generally somewhere between 4KiB and 64KiB in size. Blocks
> are larger, some getting up to 8MiB. <http://www.anandtech.com/show/2738/5>
> and <http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux> seem to
> be decent references.

Neither of those articles demonstrate an SSD performance deficit due to
the read-modify-write misalignment penalty, which is what hammers mech
disk performance. SSDs don't have to wait for the platter to come back
around for the write operation after the read, there is no head required
to seek across the platter, and they don't write the data back to the
same physical location to boot, but to a clean cell block. Thus the
write is taking place in a few hundred microseconds, not multiple
milliseconds.

> Traditionally, being unable to TRIM has caused reduced performance over time
> on SSDs. However, SSDs have such a performance increase over SMDs that I
> doubt misalignment would be noticed very much.

Totally agree. Even if all cells are 'dirty' due to a full drive, and
require an erase before a write, the erase takes only 1-2ms, and
multiple erases can occur in parallel. Something most everyone tends to
forget is that fragmentation on a mech drive will drop your performance
by a factor of 10-100 or more depending on application profile and/or
multiuser system load. And yes, all Linux filesystems DO fragment,
contrary to popular myth, very badly with mbox files (IceDove), or any
long lived constantly appended or modified files such as databases.
Filesystem fragmentation simply doesn't exist on solid state storage.

Given currently available information, I feel the performance drop due
to age issue with SSDs is over blown a bit.

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DD10AED.7030603@hardwarefreak.com">http://lists.debian.org/4DD10AED.7030603@hardwarefreak.com
 

Thread Tools




All times are GMT. The time now is 09:52 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org