Re: Scrub free disk blocks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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.

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?

-- 
Bill Davidsen <davidsen@xxxxxxx>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines


[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux