On 08/28/2010 07:21 PM, James McKenzie wrote: > JD wrote: >> 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. >> >> > If a file is moved to the trash, then the inode is retained, but the > file is now linked to the trash directory. When it is removed from the > trash and thrown away, the file is delinked. Correct. What does scrub > do when run with the -X parameter? Does it do a series of overwrites and > then move to the next data node in the free list? > > If it does that, then you are 99% assured that the data cannot be read > by 'ordinary' means. However, I would never give a drive, that has been > 'erased' to anyone I would not trust. That's just me. > > James McKenzie > Well, that's the point another op has made: If you have a failing disk, and you have credit card account data, bank account data, tax data, and many other type of proprietary product secrets, business plans, meetings records...etc, then you should consider destroying the disk utterly and thoroughly instead of sending it in for RMA. But what about the need to recover the data from such a disk? THAT's when you will DEFINITELY and MOST CERTAINLY compromise that data when you send the disk to a data recovery company. -- 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
