On Sun, Dec 25, 2016 at 1:59 AM, Dušan Čolić <dusanc@xxxxxxxxx> wrote: > Fibration is a great way to decrease fragmentation and increase throughput. > Currently there are 4 fibration plugins, lex, dot.o, ext_1 and ext_3 > and they all have their upsides and downsides. > > Proposed fibration plugin combines them all so that it combines files > with same extensions for 1, 2. 3 and 4 character extension in groups > and sorts them in same fiber group. > > With this fibration plugin all eg. xvid files would be in same group > in folder on disk sorted alphabetically so that we will avoid putting > small files between them and in that way reduce fragmentation. That > group (xvid 4 character extensions) would be among last groups under > one directory so that all small files would be written before it. > > Problem with the attached patch is that currently every fibre value is > defined as u64 (eg. static __u64 fibre_ext_3) but if I understood > correctly comments in kassign.c and fibration.c fibration part of the > key is only 7 bits long. > If that is true how did fibre_ext_3 worked? > Patch v2 addresses the problem that we have only 127 fibration groups available with 7 bits in the key so I made following groups: 1. Fibration value 0-31 - files with 1 character extension except .o files 2. Fibration value 32-60 - files with 2 character extension 3. Fibration value 61-90 - files with 3 character extension 4. Fibration value 91-120 - files with 4 character extension 5. Fibration value 121-125 - Free for some special files 6. Fibration value 126 - rest of files 7. Fibration value 127 - .o files Overlap from 128/4=32 and we use offset 30 is because control characters (those we do not use in file names) are in 0-31 range so we will never use those values. I also changed name of fibration plugin to ext_1234 to better reflect the real function of plugin. This is all still RFC as I made no changes to reiser4progs yet. Dushan > Thanks > > Dushan
Attachment:
fibration_ext_1234.2.patch
Description: Binary data
