Hi Sundar, Thank you for your code review, please see my responses below.
Sundar Yamunachari wrote: > Karen, > > *usr/src/cmd/distro_const/utils/bootroot_archive.py > *294-296: How do you determine that 10% is needed? Is 10% enough? 10% is enough now based on my experiment and my observation of existing bootroot sizes. Right now, the padding of 10mb to the bootroot size is also just an estimate. For the bootroot size, we want to find a size that's enough for the content of the bootroot plus any files that will get created during boot time. The existing method of adding 10mb padding to the bootroot size returned by "du -sk" on a ZFS directory yields the value 220mb. That value seemed to work well. Adding 10% to this new method of calculating the size arrives at around the same value, so, I think it is good enough. If we just add 10mb like we used to instead of 10%, I found that we run out of space during boot. I don't want to make it a higher percentage "just in case", because bootroot size affects the amount of required memory for Live CD, and I don't want my change to affect the memory requirement for the Live CD. > * > **usr/src/lib/install_utils/install_utils.py > > *The function dir_size() returns the size in bytes and the callers > convert them to KB. Can you return the values in KB so that callers > don't need to convert them? It's just so happens the 2 callers for dir_size() eventually wants that value in KB. I can certainly return KB, but what if some other caller of the function wants it in MB, they would need to convert anyway. So, I decided to return the most basic one, and let the caller decide what to do with it. I think it is less confusing that way. > > Does this function dir_size() works like du() in UFS? I didn't look into exactly how du() work in UFS. What I know for sure is that dir_size() returns a value that's slightly larger than the size returned by "du -sk". Probably because dir_size() rounds up file/dir sizes to the next multiple of 1024 bytes. --Karen
