On Fri, 2012-03-09 at 20:29 +0100, Joel Reardon wrote: > To me, being able to set secure erase or not as a partition level setting > makes alot of sense. The OS partition does not need it, but the user file data > partition will have it, and UBI makes sense that wear levelling is done > among all the partitions properly. Then taint status for files' > sensitivity doesn't need to be maintained. The deployer simply chooses for > this part of the FS, do they want secure deletion over the data or not, > one time at the beginning. (Compare this to the decision on whether or > not to encrypt their entire partition or later encrypting each file they > make.) Well, it makes sense. I do not insist on having a separate interface for secure deletion. But duplication of the same information in the B-tree slots and the data nodes the slots point to does not make much sense to me. I mostly look at this from the maintainability and upstreamability POW and I see that despite on the clever ideas the changes broke backward compatibility, patches are big and intrusive. From my point of view - contributors come and go but I keep maintaining this beast :-) > I'll remove the change to tree branch, and repost correctly the > version change where only data node is effected. But please, keep in mind my motivations and ensure that what I suggest makes sense from your POW! > Btw, when I was > developing it I used the last 8 bytes from the key as the key position, > because the key was 16 bytes but only 8 were used. Could you comment on > the last 8 bytes of ubifs keys? I think you can use them. But is it possible to kill these things from the data nodes themselves? We can always find it by looking up the index by the data node key, right? -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
