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
