General TC > Programming & Scripting - Unofficial

Tinkering with rebuildfstab

(1/8) > >>

CNK:
Following the recent rejected rewrite of the device identification in Tiny Core's rebuildfstab script, intended for quicker execution time, I thought I'd play around with the suggestion in the GitHub discussion that:

--- Quote ---Perhaps a large part of the time taken is by the "find" command, where adding "-maxdepth 2" may give some speedup.

--- End quote ---

Testing in Tiny Core Pure64 13, I found that this indeed sped it up to a small degree. But this suggestion also meant that there are never any desired "dev" files deeper than one level below the /sys/block directory, in which case the find command can simply be replaced by shell file name globbing. Also the DEVNAME and DEVMAJOR variables could be set using shell string manipulations instead of calling external programs.

Comparison of old/new moved to attachment (rebuildfstab_changes.txt) to avoid forum error.

While not near the stats of the earlier proposed modification, the speed-up still looks significant, and the changes here are much more minor.

(running twice to reduce cache effects, which are less significant on this particular PC than they are on others)

--- Code: ---# echo modified: ;time rebuildfstab-mod; echo original: ; time rebuildfstab; echo original: ; time rebuildfstab;echo modified: ;time rebuildfstab-mod;
modified:
real    0m 0.39s
user    0m 0.08s
sys     0m 0.18s
original:
real    0m 0.63s
user    0m 0.20s
sys     0m 0.40s
original:
real    0m 0.60s
user    0m 0.21s
sys     0m 0.38s
modified:
real    0m 0.37s
user    0m 0.07s
sys     0m 0.17s

--- End code ---

The only potential behaviour change is that the order of the entries in /etc/fstab will be different if an unpartitioned block device (eg. /dev/sda) is added there. I'm guessing that the exact order of auto-generated fstab entries doesn't matter much to anyone anyway.

Attached is the full file, where I also added ext4 at the mount options bit. I don't really think the execution time of rebuildfstab is much of an issue, it was just a fun thing to play around with, so whether TC wants to adopt this change or not, I don't really care. But if so, then go right ahead.

curaga:
Thanks for the changes. There are some issues:
- the changed DEVMAJOR line uses wrong var (i)
- it calls fstype potentially many more times
- it calls grep many times, which is what an earlier patch specifically changed to the combined awk
- if there is no glob match, the pattern is passed as-is (I guess the -b test was added for this)

It may not be simple to apply just the globbing; when I tried, it was slower.

curaga:
It does seem the find line is the main source of slowness, but also one that is not easily rewritten in shell while keeping minimal changes (to minimize the chance of regressions). If anyone is interested in tackling this, replacing just the find command with a small C program could be a nice exercise (glob(), strstr()).

hiro:
did you measure how much time blkid takes when you run it once vs. many times?
i think if find is slow then it might be bugged. it shouldn't be supposed to do very much! :O

hiro:
on my machine, running blkid for the first time take 6x as much time as find.
and after everything is cached blkid takes the same amount of time as find. and it seems like there's no cache-related variation with find.
grep is at least a magnitude faster.

i'm happy to help obsess some more about this at some point, as it's such a small contained neat thing. ;)

Navigation

[0] Message Index

[#] Next page