[PC-BSD Dev] Wild idea to speed up boot process

Radio młodych bandytów radiomlodychbandytow at o2.pl
Sat Aug 10 10:15:23 PDT 2013


On 10/08/2013 18:07, Claudio L. wrote:
> 
> On 08/09/2013 14:38, Radio młodych bandytów wrote:
>> Some thoughts:
>> 1. W/out UnionFS hacking it's unsafe in case of power failure
> Yes, I guess it would have to be resolved by using a sync mode where a
> written file gets written on both the upper and lower layers. That would
> make it easier to keep things in sync.
> Another idea would be to simply mark the files that are modified as
> "dirty" on the ram disk, and write them only to the lower layer. On next
> boot, any files that are "dirty"  would be re-read from the root
> filesystem.
OK.
> 
>> 2. It would lose ZFS end-to-end checksumming
> Not necessarily, since the ram disk backup can be on the same zfs root
> filesystem, checksum would be handled by the underlying ZFS.
One of us (or both) doesn't understand something. I meant that once data
gets read from ZFS to RAM, there's a correctness check, but later it
stays in RAM and can get corrupted.
> 
>> 3. Obviously, it wastes RAM.
> Yes, it would double the ram usage during boot, then it would be
> released. But since the ramdisk can be uncached, that would be memory
> that would otherwise be used by the zfs cache anyway. And if the ram is
> available, why not use it?
> The idea is to release all ram after booting is finished.
OK.
> 
>> 4. man mount_unionfs says: "THIS FILE SYSTEM TYPE IS NOT YET FULLY
>> SUPPORTED (READ: IT DOESN'T WORK)". Major work is needed. Though there's
>> also unionfs in FUSE, it may or may not work.
> Yes, I saw that, and doesn't inspire much confidence. But I think the
> functionality that would be required is not exactly that of the existing
> unionfs, so we wouldn't be able to use the existing unionfs anyway.
> 
I think we're getting too far (viability issues are more important than
implementation ones), but modifying unionfs seems much easier than
writing it from scratch.
> 
>> 5. We should measure the bottlenecks of the current procedure before
>> trying to improve it. Is it going to be faster at all?
> A lot of people already did that. Just look at the speedups you get from
> booting on a normal hard disk w/SSD caching (Momentus XT?), which is
> basically the same I'm proposing: a persistent cache that provides high
> IOPS on top of a standard filesystem layer.

This is very different. It doesn't have to read data from disk before
use and if data is heavily fragmented, this is a major cost.
We have the following cases:
A) data is stored sequentially and the boot process accesses it sequentially
B) data is stored sequentially, accessed randomly
C) data is stored randomly, accessed randomly
On the 1st system install, it's most likely C, but maybe we could
manipulate it to B
After lots of use and system update, it will end up in C and I see no
way to prevent it.
A is for completeness, I don't think that it happens.
The cache that you propose improves only B. Momentus XT / persistent
L2ARC - B and C and possibly A too.
Still, this is theory. If you've seen numbers that you can share, please do.

> 
>> 6. The illumos camp works on persistent L2ARC. It's a much better
>> option, though requires hardware that not everybody has.
> 
> Obviously, if you already have cache with high IOPS (like an SSD), the
> improvement from using a ram cache will be much less. But I think it
> could still provide some speedup.
> This idea is more to provide the benefits of a persistent cache to
> everybody, whether you have one or not.
> 
> Claudio
> _______________________________________________
> Dev mailing list
> Dev at lists.pcbsd.org
> http://lists.pcbsd.org/mailman/listinfo/dev


-- 
Twoje radio


More information about the Dev mailing list