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