* Andreas Dilger <adilger@dilger.ca> hat geschrieben:> The "lifetime writes" value has not been around forever, so if the > filesystem was originally created and populated on an older kernel > (e.g. using ext3) it would not contain a record of those writes.It was created as stable ext4 in the first place. So only if there was a stable ext4 release which didn't update the "lifetime writes" value this could be the case.> There is also some potential loss if the filesystem isn't unmounted > cleanly.Yea, that *might* be it - but that only supports my statement, that this value is mainly bogus.> It definitely _can_ be used to monitor the writes to a particular > filesystem over the past 24h, which is what the original poster was > asking about.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. Also the value is only available in granularity of 1 GB (plus minus 512MB) - at least in my case. So, in any case, I wouldn't trust that value for any purposes at all. 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. Regards, Bodo
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. 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.> 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: if (sb->s_kbytes_written) { fprintf(f, "Lifetime writes: "); if (sb->s_kbytes_written < POW2(13)) fprintf(f, "%llu kB\n", sb->s_kbytes_written); else if (sb->s_kbytes_written < POW2(23)) fprintf(f, "%llu MB\n", (sb->s_kbytes_written + POW2(9)) >> 10); else if (sb->s_kbytes_written < POW2(33)) fprintf(f, "%llu GB\n", (sb->s_kbytes_written + POW2(19)) >> 20); else if (sb->s_kbytes_written < POW2(43)) fprintf(f, "%llu TB\n", (sb->s_kbytes_written + POW2(29)) >> 30); else fprintf(f, "%llu PB\n", (sb->s_kbytes_written + POW2(39)) >> 40); } 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 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. If it's not helpful enough for your use case, don't use it. Certainly if the SSD has information available via S.M.A.R.T., it's better to use that instead. But if a crappy CF device doesn't have S.M.A.R.T, then I'm afraid this is the best that we can offer.... - Ted
* "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