On Wed, 2012-06-20 at 09:57 -0500, Leonid Isaev wrote
> Well, SSD's limited number of write cycles is largerly a myth these days [snip]
>

A storage drive should be usable in quasi every way. We aren't talking
about an USB stick or DVD RW . If you need tricks to enlarge the
lifetime, than it's a useless device. I already quoted the Wiki
regarding to the lifetime. It's said that they have a longer lifetime
than modern hard disk drives usually have got. If they shouldn't last
long, just because Linux does write to often log files and you have to
use tricks and need an additional hard disc drive, than this new devices
are crap. Again, what's about noatime etc.? The way they're handled
might be important in a way it's important for HDDs too, e.g. does the
FS require something comparable to M$ FS defragmentation? But if a user
needs to take care about read and write cycles for a storage device IMO
make the usage of a computer too complicated. This is a task for the FS,
the device's controller or whatever.
How often does we need a log file after a regular shutdown? If you copy
them for shutdown, you simply can abandon those files completely.

Just an opinion,
Ralf

On Wed, 20 Jun 2012 17:20:55 +0200
Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:

> On Wed, 2012-06-20 at 09:57 -0500, Leonid Isaev wrote
> > Well, SSD's limited number of write cycles is largerly a myth these days
> > [snip]
> >
>
> [...]
> The way they're handled might be important in a way it's important for
> HDDs too, e.g. does the FS require something comparable to M$ FS
> defragmentation?

Well, it all depends on a task at hand. Windows 7 is quite efficient on SSDs
for a general purpose system. And NTFS, if properly configured, is at the same
level of performance as ext4/btrfs maybe better, at least in my experience.

> But if a user
> needs to take care about read and write cycles for a storage device IMO
> make the usage of a computer too complicated. This is a task for the FS,
> the device's controller or whatever.

Or OS

> How often does we need a log file after a regular shutdown? If you copy
> them for shutdown, you simply can abandon those files completely.

System logs are always useful and must not be volatile.

>
> Just an opinion,
> Ralf
>

--
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

On 06/20/2012 05:20 PM, Ralf Mardorf wrote:

On Wed, 2012-06-20 at 09:57 -0500, Leonid Isaev wrote

Well, SSD's limited number of write cycles is largerly a myth these days [snip]


A storage drive should be usable in quasi every way. We aren't talking
about an USB stick or DVD RW . If you need tricks to enlarge the
lifetime, than it's a useless device. I already quoted the Wiki
regarding to the lifetime. It's said that they have a longer lifetime
than modern hard disk drives usually have got. If they shouldn't last
long, just because Linux does write to often log files and you have to
use tricks and need an additional hard disc drive, than this new devices
are crap. Again, what's about noatime etc.? The way they're handled
might be important in a way it's important for HDDs too, e.g. does the
FS require something comparable to M$ FS defragmentation? But if a user
needs to take care about read and write cycles for a storage device IMO
make the usage of a computer too complicated. This is a task for the FS,
the device's controller or whatever.
How often does we need a log file after a regular shutdown? If you copy
them for shutdown, you simply can abandon those files completely.

Just an opinion,
Ralf

OK guys. When I bought my ssd, I read too that this story of short
lifetime is a myth. As it is now clear to me that writing /var/log into
RAM is a totally fullish idea in case of crash, I am back to my original
fstab, with no entry for /var/log.

I will then take my time to understand rsyslog or syslog-ng.
Ty all for your wise advises.

On Wed, Jun 20, 2012 at 14:38:27 +0530, gt wrote:
> Hello Arno
>
> Sorry for the offtopic bit, but i have noticed that your threads tend to
> branch out from some other thread, many times.
>
> I believe that you use the reply button on an existing topic and then
> start your own thread. This looks very weird and is also confusing, as i
> think your message is related to the one you forked, while it is not.
>
> Please always start a new thread



For the mutt users, just press "#" to decouple the message from the parent
thread. :-)

</offtopic>


Geert



--
geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!

> On Wed, Jun 20, 2012 at 14:38:27 +0530, gt wrote:
> For the mutt users, just press "#" to decouple the message from the parent
> thread. :-)

Not in my .muttrc. What option is this? I might have unbound the key for
some reason
>
> </offtopic>

Manolo

On Wed, Jun 20, 2012 at 16:14:46 -0400, Manolo Martínez wrote:
> > On Wed, Jun 20, 2012 at 14:38:27 +0530, gt wrote:
> > For the mutt users, just press "#" to decouple the message from the parent
> > thread. :-)
>
> Not in my .muttrc. What option is this? I might have unbound the key for
> some reason


break-thread.

The inverse is "&" link-thread (to fix messages from stupid MUA's that
don't include an In-Reply-To header).


Geert


--
geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!

Manolo Martínez, Wed 2012-06-20 @ 16:14:46-0400:
> > On Wed, Jun 20, 2012 at 14:38:27 +0530, gt wrote: For the mutt
> > users, just press "#" to decouple the message from the parent
> > thread. :-)
>
> Not in my .muttrc. What option is this? I might have unbound the key
> for some reason

The mutt function is called break-thread.

On 06/20/2012 10:21 PM, Geert Hendrickx wrote:

On Wed, Jun 20, 2012 at 16:14:46 -0400, Manolo Martínez wrote:

On Wed, Jun 20, 2012 at 14:38:27 +0530, gt wrote:
For the mutt users, just press "#" to decouple the message from the parent
thread. :-)

Not in my .muttrc. What option is this? I might have unbound the key for
some reason


break-thread.

The inverse is "&" link-thread (to fix messages from stupid MUA's that
don't include an In-Reply-To header).


Geert


Another day with something new : the Mutt command line MUA. Never boring
when Linuxing.

Will have a look at it then.

On Wed, Jun 20, 2012 at 09:51:03PM +0200, Geert Hendrickx wrote:
> On Wed, Jun 20, 2012 at 14:38:27 +0530, gt wrote:
> > Hello Arno
> > [snip]
> > Please always start a new thread
> For the mutt users, just press "#" to decouple the message from the parent
> thread. :-)
>
> </offtopic>

Thanks for the advice. I knew about the feature, but never got around to
using it.

> OK guys. When I bought my ssd, I read too that this story of short
> lifetime is a myth. As it is now clear to me that writing /var/log into
> RAM is a totally fullish idea in case of crash, I am back to my original
> fstab, with no entry for /var/log.
> I will then take my time to understand rsyslog or syslog-ng.
> Ty all for your wise advises.

Not exactly. It's true and as your filesystem fills up it becomes more
of a problem. However modern drives such as with sandforce controllers
reserve around 20% of the drive so that the problem is avoided for the
lifetime of a drive. The picture of data preservation, reliability and
shock between SSD and HDD also has many intricacies depending on your
concerns. The picture is far from simply SSD rules in all situations
except capacity/£.



__________________________________________________ ______

Why not do something good every day and install BOINC.
__________________________________________________ ______