Messages in this thread | | | Date | Wed, 19 Jul 2000 18:08:22 -0400 (EDT) | From | "Mike A. Harris" <> | Subject | Re: chattr and ext2 extended attributes |
| |
On Wed, 19 Jul 2000, Ookhoi wrote:
>> There were a couple of patches for ext2 undelete, but in the end people >> decided that it is possible to implement undelete in libc, so it was >> better not to put this into the kernel. Whether code currently exists >> to do this for a recent kernel, I'm not sure. As for e2compr, I think >> code is slowly making its way into the mainstream - e2fsprogs is now >> starting to have support for it... > >If it works, then you can just take a huge textfile and it will be >compressed immediately if you put the c flag on it? Or do you have to >read/write it afterwards, or do you even have to start with a touch >file?
It works like the similar feature in NT does. Setting the compression flag on a file will compress that file immediately. Setting it on a directory, indicates that any files put in the dir should be compressed as well (inheritance).
You need to use e2compr patches though, and also update all utils that manage the filesystem (fsck, etc..) so that they are e2compr aware.
>> > We now have "noatime" and "nodiratime" options in kernel. Is the >> > "A" flag supported now at all? >> >> Yes, it allows noatime to be set on an individual file basis, while >> the noatime flag is for the whole filesystem. > >What does nodiratime do exactly? A quick grep on the kernel source >didn't educate me, and man mount only mentions noatime.
ATIME is the file/directory's access time. It is set every time a file is accessed at all - read/write. Since this field is of minimal use in a lot of cases, and since it causes enough filesystem overhead to set, quite often it is better to have the ability to disable it. The mount noatime and nodiratime disables the atime on files and dirs respectively for the whole mounted filesystem. A noatime flag stored in the directory however would allow disabling of atime on a per file or directory basis. IMHO it would be a very useful thing to have. I played with this flag a bit, and it does not appear to work.
>> like you to believe this). I read a paper that suggested 27 passes of >> specific byte codes + random data were necessary to even have a hope of >> having the data be securely deleted. > >Hmm, do you have an url about this? How is it possible that data is >still on disk if you write 0's and 1's over them? (or am I missing >something?).
They have equipment that can read data off disks even after it has been erased and written over many times. Supposedly up to 9 times overwritten, but I've heard that it can be read much deeper than that. It most likely is because of minute amounts of residual magnetism. The government does this, and likely anyone with similar capacity's as well as data recovery houses.
By writing over the sectors with random garbage 40 times, it ensures the highest chance that recovery of whatever was there is next to impossible. Think of it like writing a note on a pad of paper with a normal yellow pencil, or a pen. After you tear the note off, it is gone right? Not if you pressed hard enough that the pattern of letters is impressed upon the next piece of paper. Each piece of paper has an imprint of what you wrote, although each successive paper will have less and less of the impression. New messages written on the top piece of paper will gradually mix up the impressions. Much like a piece of carbon paper that is used over and over again too. The first time it is used, you can read it. After many uses, it becomes difficult if not impossible to see what was written. Same goes for the hard disk.
Hope this helps. TTYL
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate
... Our continuing mission: To seek out knowledge of C, to explore strange UNIX commands, and to boldly code where no one has man page 4.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |