Scrub free disk blocks

[JD]

  On 08/28/2010 06:35 PM, Bill Davidsen wrote:
> JD wrote:
>>    On 08/28/2010 05:42 PM, Patrick O'Callaghan wrote:
>>> On Sat, 2010-08-28 at 15:12 -0700, JD wrote:
>>>> On 08/28/2010 01:53 PM, Patrick O'Callaghan wrote:
>>>>> On Sat, 2010-08-28 at 10:46 -0700, JD wrote:
>>>>>> You need to study filesystem architecture to gain better
>>>>>> understanding.
>>>>> If you can't explain what you mean, just say so.
>>>>>
>>>>> poc
>>>>>
>>>> I can explain it alright - and I tried to tell you that a program
>>>> can access all blocks of a file, direct and indirect, given that
>>>> tha program has the access permissions for that file, but you ignored
>>>> it. Direct and Indirect blocks are only meaningful to the inode layer.
>>>> The file's offset will be computed and a block number arrived at. If
>>>> that block number is outside the range of the direct blocks, then the
>>>> indirect blocks are accessed. Enough said.
>>>> Explaining FS architecture is beyond the scope of this list, and
>>>> certainly beyond this thread.
>>> I've been using Unix since 1975 and am very well aware of how the
>>> direct/indirect addressing scheme works. And I still fail to see what
>>> this has to do with the scrub command. Are you saying that scrub
>>> overwrites these blocks when deleting a file? If so, what is your basis
>>> for saying so, given that the manpage explicitly states that "only the
>>> data in the file (and optionally its name in the directory entry) is
>>> destroyed"?
>>>
>>> OTOH if you're saying these blocks are irrelevant, you're contradicting
>>> your original requirement of scrubbing any free space.
>>>
>>> poc
>>>
>> Let me quote to you what YOU wrote:
>> On 08/28/2010 06:22 AM, Patrick O'Callaghan wrote:
>>>  From scrub(1):
>>>
>>> -X, --freespace
>>> Create specified directory and fill it with files until write returns
>>> ENOSPC (file system full),
>>> then scrub the files as usual. The size of each file can be set with
>>> -s, otherwise it will be the
>>> maximum file size creatable given the user’s file size limit or 1g if
>>> umlimited.
>>>
>>> However note that neither of these methods guarantees to scrub indirect
>>> blocks in the filesystem that were used to create the space-filling
>>> files. Maybe they do, maybe they don't, it's not clear.
>>>
>>> poc
>> It was you who made the off-the-wall and totally wrong statement that
>> indirect blocks of files created by the scrub process ARE NOT SCRUBBED!
>>
> Since you imply that they are, please identify the method of doing so, since the
> documentation and source only seem to scrub the file *content* and not the
> indirect (ie. inode) blocks at all. There's code to zero the filename, and maybe
> truncating the file would clear the primary inode and release the indirect
> blocks, but I think inode clearing is f/s dependent, not necessarily a given.
>
> I can see how the inode indirect blocks might get zeroed (on some filesystems),
> but I see no way to cause scrubbing with multiple random patterns.
The data blocks, be they direct or indirect data blocks ( an 'attribute' 
- and I use the word
attribute here loosely to make a point - is only meaningful to the inode 
layer),
has absolutely NOTHING to do with what the scrub program does to ALL the 
blocks of a file.
So, just get off of this whole thing about direct and indirect blocks.
This is irrelevant to the subject of scrubbing a file.
Rest assured scrub will get all of a file's blocks.
>> You have exposed your ignorance of the filesystem architecture, and
>> mentioned something you vaguely remember the name of, and totally
>> embarrassed yourself before a very large audience.
>>
> Having jumped all over Patrick, please point us to the filesystem or other code
> to scrub the inode indirect blocks.
As stated above.
> Don't read this as a claim the indirect blocks need to be scrubbed, but do tell
> us just how that scrubbing occurs. You haven't confused indirect block
> (filesystem metadata) with the data blocks described by the indirect blocks,
> have you?
>
A filesystem's metadata are things like inodes and cylinder groups, and 
superblocks.
These are NOT indirect blocks. Do not confuse filesystem metadata with a 
file's
data.
When a file is deleted, then the inode for that file is returned to the 
free list.
That inode does not have a file's content. Only info about that file, 
such as
owner, permissions, ..  and the addresses of the blocks holding the data of
that file.