search for: optimalisation

On Oct 16, 2014, at 10:25 AM, Bodo Thiesen <bothie@gmx.de> wrote: > * Andreas Dilger <adilger@dilger.ca> hat geschrieben: > >> You can see in the ext4 superblock the amount of data that has been >> written to a filesystem over its lifetime: >> >> Note that this number isn't wholly accurate, but rather a guideline. > > Is is more like a

* Andreas Dilger <adilger@dilger.ca> hat geschrieben: > You can see in the ext4 superblock the amount of data that has been > written to a filesystem over its lifetime: > > Note that this number isn't wholly accurate, but rather a guideline. Is is more like a completely bogus value at best: # LANG=C df -h / | grep root /dev/root 3.7T 3.6T 73G 99% / # grep [0-9]

Something else that you might want to do is count the number of journal commits that are taking place, via a command like this: perf stat -e jbd2:jbd2_start_commit -a sleep 3600 This will count the number of jbd2 commits are executed in 3600 seconds --- i.e., an hour. If you are running some workload which is constantly calling fsync(2), that will be forcing journal commits, and those turn into

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

On Oct 8, 2014, at 10:28 AM, Jelle de Jong <jelledejong at powercraft.nl> wrote: > Hello everyone, > > I been using CF cards for almost more then 7 years now with ext > file-system without any major problems on ALIX boards. > > Last year I took 30 other systems in production with ext4 and the CF > cards been dropping out pretty fast, it may have been a bad batch but

* 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, I been using CF cards for almost more then 7 years now with ext file-system without any major problems on ALIX boards. Last year I took 30 other systems in production with ext4 and the CF cards been dropping out pretty fast, it may have been a bad batch but I do want to look at it. I don't think the devices writes a lot of IO (is

...came a bit warm, but no real issues. > No experience with E6420 though, sorry. > > Greetings, Johan Thanks for the feedback. Did you have to install or configure any packages differently for the laptops than you would a desktop? Hello, Not realy. I don't use any packages for battery optimalisation or anything like that. By coincidence, I will have latitude E 6420 's available for testing on thursday. Greetz, Johan _______________________________________________ CentOS mailing list CentOS at centos.org http://lists.centos.org/mailman/listinfo/centos

I did Dovecot profiling on huge e-mail system, and p_strdup was very high on list. I do minor change: p_strdup: /* for (len = 0; (str)[len] != '\0'; ) len++; len++; */ len = strlen(str) + 1; p_strndup: /* len = 0; while (len < max_chars && ((const char *) str)[len] != '\0') len++; */ len = strnlen(str, max_chars); And after changes strdup drop down on the

THE SCHEMA IN THE MODEL a small write up on ''putting the schema in the model'' This is a write up on an issue best covered in a mailing list thread of Januari 2006 (see the links in the text), I repost it because I think it deserves a place on the agenda. == Why? == I was switching back and forward between the model files and the schema.rb -- off course I have

Figures to Facts is a company specialized in BI dashboard and report creation on sales and marketing data. We are a small but fast growing company, working for the largest Fast Moving Consumer Goods enterprises in the world. We are currently looking for an R programmer, who will become responsible for the complete 'data environment' in our company. Main responsibilities: - You