Skip to content
Snippets Groups Projects
Forked from Reform / reform-boundary-uboot
Source project has a limited visibility.
  • Stefan Brüns's avatar
    a9fa0ed1
    ext4: After completely filled group, scan next group from the beginning · a9fa0ed1
    Stefan Brüns authored
    
    The last free block of a block group may be in its middle. After it has
    been allocated, the next block group should be scanned from its beginning.
    
    The following command triggers the bad behaviour (on a blocksize 1024 fs):
    
    ./sandbox/u-boot -c 'i=0; host bind 0 ./disk.raw ;
    	while test $i -lt 260 ; do echo $i; setexpr i $i + 1;
    		ext4write host 0:2 0 /X${i} 0x1450; done ;
    	ext4write host 0:2 0 /X240 0x2000 ; '
    
    When 'X240' is extended from 5200 byte to 8192 byte, the new blocks should
    start from the first free block (8811), but it uses the blocks 8098-8103
    and 16296-16297 -- 8103 + 1 + 8192 = 16296. This can be shown with
    debugfs, commands 'ffb' and 'stat X240'.
    
    Signed-off-by: default avatarStefan Brüns <stefan.bruens@rwth-aachen.de>
    Reviewed-by: default avatarLukasz Majewski <l.majewski@samsung.com>
    a9fa0ed1
    History
    ext4: After completely filled group, scan next group from the beginning
    Stefan Brüns authored
    
    The last free block of a block group may be in its middle. After it has
    been allocated, the next block group should be scanned from its beginning.
    
    The following command triggers the bad behaviour (on a blocksize 1024 fs):
    
    ./sandbox/u-boot -c 'i=0; host bind 0 ./disk.raw ;
    	while test $i -lt 260 ; do echo $i; setexpr i $i + 1;
    		ext4write host 0:2 0 /X${i} 0x1450; done ;
    	ext4write host 0:2 0 /X240 0x2000 ; '
    
    When 'X240' is extended from 5200 byte to 8192 byte, the new blocks should
    start from the first free block (8811), but it uses the blocks 8098-8103
    and 16296-16297 -- 8103 + 1 + 8192 = 16296. This can be shown with
    debugfs, commands 'ffb' and 'stat X240'.
    
    Signed-off-by: default avatarStefan Brüns <stefan.bruens@rwth-aachen.de>
    Reviewed-by: default avatarLukasz Majewski <l.majewski@samsung.com>