[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: CF Card wear optimalisation for ext4



* "Theodore Ts'o" <tytso mit edu> hat geschrieben:

> On Thu, Oct 16, 2014 at 11:01:35PM +0200, Bodo Thiesen wrote:
> > 
> > Since it never get's updated unless the file system is unmounted, it can
> > only be used for a 24 hours test by mounting the file system now,
> > unmounting it 24 hours from now and then taking the difference.
> 
> It also gets updated if the file system syncfs(2) or sync(2) system
> call.

Then sync(1) doesn't call sync(2) ... wait ...

# strace sync
[...]
sync()                                  = 0
[...]

hmmm ...

So, why didn't the value get updated after writing some GB of data (dd
for testing yesterday)?

# sync
# echo 3 > /proc/sys/vm/drop_caches
# tune2fs -l /dev/sda | grep Lifetime
Lifetime writes:          2503 GB
# uptime
 01:11:10 up 2 days, 22:26, 15 users,  load average: 0.98, 0.99, 1.02

So, I guess you have to recheck the code for that statement because it
really doesn't reflect reality.

> But if you crash, any writes since the last syncfs(2), sync(2),
> or umount(2) call on the file system can get lost, yes.

"Will", not "can".

>> Also the value is only available in granularity of 1 GB (plus minus
>> 512MB) - at least in my case.
> This is what dumpe2fs is currently using:
> [printing prefixes]
> What we are doing was deliberate, in an effort to display things in a
> user-friendly fashion that was hopefully still useful.  If you'd like
> to propose something different, please send patches and I'll consider it.

I quess a simple cmd line option "--raw-values" would be cool not only for
dumpe2fs but tune2fs as well - that just switches off this - in fact not
*that* bad - default behavior on explicit demand.

So, if you're going to include such a patch for some[tm] tools, I'd be
happy to do it, just give me some time for that ;)

>> I did test /sys/fs/ext4/sda/lifetime_write_kbytes now, that seems to be
>> somewhat less bogus, so *that* might actuall be usable for the 24 hours
>> test. But I wasn't talking about that when I said, that this lifetime
>> thing is bogus.
> Bogus is in the eye of the beholder.  It's not perfect, and if your
> system is regularly crashing, then it will be much less perfect.

It was because of the rcu-bug which I didn't know and I did actually blame
fglrx for the crashes - which was - as it turned out - not fair. My system
is table now. (the uptime of almost 3 days was a deliberate shut down ;)

> If it's not helpful enough for your use case, don't use it.

Oh, actually, I don't need that value at all, Jelle needs it. But yes, it
seems good enough for his use case. But he has to use the sys interface
not tune2fs/dumpe2fs for the lifetime writes value.

Regars, Bodo


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]