O que você está pedindo é impossível. Ou, mais precisamente, há um custo a pagar ao excluir um diretório e seus arquivos; se você não pagar no momento da exclusão, terá que pagá-lo em outro lugar.
Você não está apenas removendo um diretório - isso seria quase instantâneo. Você está removendo um diretório e todos os arquivos dentro dele e também recursivamente removendo também todos os seus subdiretórios. Remover um arquivo significa decrementar sua contagem de links e, em seguida, marcar seus recursos (os blocos usados para o conteúdo de arquivos e metadados de arquivos e o inode se o sistema de arquivos usar uma tabela de inode) como livres se a contagem de links atingir 0 e o arquivo não for abrir. Essa é uma operação que precisa ser feita para cada arquivo na árvore de diretórios, portanto, o tempo que leva é pelo menos proporcional ao número de arquivos.
Você pode atrasar o custo de marcar os recursos como gratuitos. Por exemplo, existem sistemas de arquivos coletados por coleta de lixo, nos quais é possível remover um diretório sem remover os arquivos contidos nele. Uma execução do coletor de lixo detectará os arquivos que não podem ser acessados através da estrutura de diretórios e os marcará como livres. Fazer rm -f directory; garbage-collect em um sistema de arquivos garbage collected faz as mesmas coisas que rm -rf em um sistema de arquivos tradicional, com diferentes triggers. Existem poucos sistemas de arquivos coletados por coleta de lixo porque o GC é uma complexidade adicional que raramente é necessária. O tempo do CG pode chegar a qualquer momento, quando o sistema de arquivos precisa de alguns blocos livres e não encontra nenhum, então o desempenho de uma operação seria dependente do histórico passado, não apenas da operação, o que geralmente é indesejável. Você precisaria executar o coletor de lixo apenas para obter a quantidade real de espaço livre.
Se você quiser simular o comportamento do GC em um sistema de arquivos normal, você pode fazê-lo:
mv directory .DELETING; rm -rf .DELETING &
(omiti muitos detalhes importantes, como verificação de erros, como resiliência à perda de energia, etc.) O nome do diretório torna-se inexistente imediatamente; o espaço é recuperado progressivamente.
Uma abordagem diferente para evitar o pagamento do custo durante a remoção sem GC seria pagá-lo durante a alocação. Marque a árvore de diretórios como excluída e passe pelos diretórios excluídos ao alocar blocos. Isso seria difícil de conciliar com hard links, mas em um sistema de arquivos sem hard links, isso pode ser feito com O (1) aumento de custos na alocação. No entanto, isso tornaria a operação mais comum (criação ou ampliação de um arquivo) mais cara, com o único benefício de ser uma operação relativamente rara (remover uma árvore de diretórios grande) mais barata.
Você poderia remover em massa uma árvore de diretórios se essa árvore fosse armazenada como seu próprio conjunto de blocos. (Nota: estou usando a palavra "pool" em um significado diferente do "pool de armazenamento" do ZFS. Não sei qual a terminologia correta.) Isso pode ser muito rápido. Mas o que você faz com o espaço livre? Se você reatribui-lo a outro pool, isso tem um custo, embora muito menos do que excluir arquivos individualmente. Se você deixar o espaço como espaço de reserva não utilizado, não poderá recuperá-lo imediatamente. Ter um pool individual para uma árvore de diretórios significa custos adicionais para aumentar ou reduzir o tamanho desse pool (seja de forma dinâmica ou explicitamente). Tornar a árvore seu próprio conjunto de armazenamento também aumenta o custo de mover arquivos para dentro e fora da árvore.