Am 20.09.2015 um 12:41 schrieb Alexander Holler:
Am 20.09.2015 um 04:21 schrieb Theodore Ts'o:
As far as what you want to do next, you have a personal "proof of
concept" patch that seems to work well enough for you. Great! I'm
sure you can keep using it for your own purposes. If you can convince
someone with the skills to get the patch to an upstreamable state, it
is my judgement that this is doable, so this puts your feature in a
much better state than the FALLOC_FL_NO_HIDE_STALE flag. However,
there is still a non-trivial amount of work left to do to turn your
"proof of concept" patch into something that is upstremable, including
changing the interface to using the FS_SECRM_FL flag. And your
whining that other people should change *their* priorities to match
*yours* is not likely to help.
Besides that I have absolutely no knowledge about
FALLOC_FL_NO_HIDE_STALE or the FS_SECRM_FL flag, I've never whined. I've
complained about the tone very often used on this list. And it doesn't
Just to explain why I'm still quiet happy with my very simple approach
to use a simple modified discard mechanism to wipe files:
My main use case (an that of several other people I know) is to have a
simple way to wipe photos on sd-cards or to wipe other files I've copied
once onto (vfat-formatted) usb-sticks while never having modified these
files afterwards.
And that works like a charm and doesn't need complicated patches which
might be very different for every filesystem.
And the check (and returning an error) if a file is already in use when
trying to wipe it, makes it unnecessary to introduce something more
complicated to schedule wiping. I also don't care if something is left
in swap or similiar. So instead of trying to perfectly solve a big
problem (which already was unsuccessful tried in case of the Linux
kernel), I've just reduced the problem to fit the main use cases most
people have and solved that with a very simple, but working approach.
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
