[systemd-devel] fstrim "cron" job

[Reindl Harald]

Am 21.12.2013 15:23, schrieb Kay Sievers:
> On Sat, Dec 21, 2013 at 3:11 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>> Am 21.12.2013 14:44, schrieb Kay Sievers:
>>> Trimming should be the job of the filesystem, not for a nasty cron
>>> job. We do not want to support legacy filesystems with upstream
>>> shipped systemd units.
>>
>> doing it permanently on the fs-layer degrades all time performance
>> doing it in a cron job regulary does not affect performance that way
> 
> No. Modern filesystems are like kernel services not silent and dumb
> dong nothing in the background. They can do whatever they need to do
> in whatever manner, and they can do it right.

that's no the point

the point is that mountig with trim means every time you delete something
the physical disks get notified, doing it once per day avoids this overhead

>>> Readahead is pointless and wrong enough already to ship and enable in
>>> systemd; using slows down bootup on all of my machines
>>
>> yes and no
>>
>> the question is not only hwo long the boot process itself takes
>> how long does it take until you KDE/GNOME session is fully loaded
>>
>> there are always a few seconds between boot and enter username / pwd
>> in this time window readahead already loads things from disk which
>> are need due login - the summary of both is the interesting number
> 
> I have auto-login and using read-ahead was just slower

yes because auto-login - for the sake of security not to recommend
in that case you gain nothing because there is no time window
between boot and login

> Maybe the new block multi-queue stuff changes the picture; but in 
> general I'm convinced that read-ahead is a tool from the past on 
> current modern systems/SSDs, it should no longer be enabled by default

define modern systems

as long as SD cards are dying silent without any error and claiming
data are written while delete, format with several filesystems and
overwrite with /dev/zero as well as /dev/urandom leads to after
remove the card and insert it again the old data is still there
like all the overwrites and formats never happened i stay on
not so modern RAID10 spindles with 4 to 12 disks which are not
really slower for most usecases, more reliable and much larger

flash devices typically are dying from one moment to the next
while a classical harddisk starts to throw errors long before

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20131221/ef4b2306/attachment-0001.pgp>