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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:12 EST