linux-kernel - Re: [RFC][PATCH] ChunkFS: fs fission for faster fsck

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4630D9A5.9070105@ksu.edu>
Date:	Thu, 26 Apr 2007 11:56:05 -0500
From:	Amit Gud <gud@....edu>
To:	Jeff Dike <jdike@...toit.com>
CC:	Valerie Henson <val_henson@...ux.intel.com>,
	Nikita Danilov <nikita@...sterfs.com>,
	David Lang <david.lang@...italinsight.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	riel@...riel.com, zab@...bo.net, arjan@...radead.org,
	suparna@...ibm.com, brandon@...p.org, karunasagark@...il.com
Subject: Re: [RFC][PATCH] ChunkFS: fs fission for faster fsck

Jeff Dike wrote:
> On Thu, Apr 26, 2007 at 10:53:16AM -0500, Amit Gud wrote:
>> Jeff Dike wrote:
>>> How about this case:
>>>
>>> 	Growing file starts in chunk A.
>>> 	Overflows into chunk B.
>>> 	Delete file in chunk A.
>>> 	Growing file overflows chunk B and spots new free space in
>>> chunk A (and nothing anywhere else)
>>> 	Overflows into chunk A
>>> 	Delete file in chunk B.
>>> 	Overflow into chunk B again.
>>>
>>> Maybe this is not realistic, but in the absence of a mechanism to pull
>>> data back from an overflow chunk, it seems at least a theoretical
>>> possibility that there could be > 1 continuation inodes per file per
>>> chunk.
>>>
>> Preventive measures are taken to limit only one continuation inode per 
>> file per chunk. This can be done easily in the chunk allocation 
>> algorithm for disk space. Although I'm not quite sure what you mean by 
>> "Delete file in chunk A". If you are referring to same file thats 
>> growing, then deletion is not possible, because individual parts of any 
>> file in any chunk cannot be deleted.
> 
> No, I'm referring to a different file.  The scenario is that you have
> a growing file in a nearly full disk with files being deleted (and
> thus space being freed) such that allocations for the growing file
> bounce back and forth between chunks.
> 

In such scenario either lot of continuation inodes < number of chunks 
would be created or lot of sparse pieces would be created. But we can 
certainly enforce the constraint of one continuation inode per file per 
chunk, excluding the file's primary chunk in which it started.


AG
-- 
May the source be with you.
http://www.cis.ksu.edu/~gud

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/