72 replies to this topic

[MiLo]

As soon as the unlink action starts, the file is no more visible in the file system and you can even have a new file with exactly the same name from that point.

Actually, that's only the case AFTER unlink returns, not while it's running.

So IMHO there is no need to rename the file, just start the unlinking in a separate thread. I can see a source of race conditions there, though, need to be careful.

Starting a thread for each delete call is simply a bad idea, I guess you'll agree. So what remains is to have a single thread do all the delete calls on your behalf, but that leads to files remaining visible for several seconds if you remove a dozen or so. The solution to that is to rename the file first, and then add it to the thread's queue, and this is exactly what it does now.

What we SHOULD do is make the "slow delete" function no longer the default. Maybe remove it alltogether, as even the old boxes will already have evolved to ext4.

Note that normal users never see this, the GUI implements "delete" as "move to trash". It's the trashcan purging that will actually delete them.

[WanWizard]

Can't it be made automagical? i.e. check if it's ext2/ext3, and if not, skip the slow delete function?

[Erik Slagter]

So what remains is to have a single thread do all the delete calls on your behalf, but that leads to files remaining visible for several seconds if you remove a dozen or so.

And that is a problem? Otherwise first rename it to something starting with a dot or even move it to an invisible directory ("trashcan" comes to mind...)
 

The solution to that is to rename the file first, and then add it to the thread's queue, and this is exactly what it does now.

Exactly like that
 

What we SHOULD do is make the "slow delete" function no longer the default. Maybe remove it alltogether, as even the old boxes will already have evolved to ext4. Note that normal users never see this, the GUI implements "delete" as "move to trash". It's the trashcan purging that will actually delete them.

No we SHOULD NOT do that. It's a workaround that many of us don't need nor need (think of all NAS users...)

[Erik Slagter]

Can't it be made automagical? i.e. check if it's ext2/ext3, and if not, skip the slow delete function?

Hmmm, sounds like if(model) then { workaround }, I'd favour another way of detection whether it's necessary, if possible, of course.

[WanWizard]

I don't have any preference.

 

I think there are only two requirements:

- file should no longer be visible after it has been deleted in the GUI

- delete process should not inhibit the I/O to the storage device (whether local or remote)

[anudanan]

Your are right, EXT3 is a problem. Unlink works fine on EXT2 and EXT4 wihtout interrupting recordings, In the past I used an et9200 for recording with EXT2 instead of EXT3

 

My EMC normally also  moves the deleted files first into a trashcan for reverting user mistakes

 

But if I delete the files per hand from the trashcan than it works as I have written in my last posts.

Edited by anudanan, 22 February 2018 - 20:01.

[Erik Slagter]

You might want to try these alternatives on ext3:

 

- turning off journalling altogether (making it de facto ext2)

- use journalling for metadata only not data (although this is default and probably won't help here)

- don't use synchronous journalling, that will propbably help (mount the partition using data=writeback), this will probably help

 

IMHO this is a better approach then working around it.

[MiLo]

What we SHOULD do is make the "slow delete" function no longer the default. Maybe remove it alltogether, as even the old boxes will already have evolved to ext4. Note that normal users never see this, the GUI implements "delete" as "move to trash". It's the trashcan purging that will actually delete them.

No we SHOULD NOT do that. It's a workaround that many of us don't need nor need (think of all NAS users...)

I don't understand what you're saying here, you say "no" in the first part and give a rationale for a "yes" in the second part.

(I actually have a commit ready to make just calling "unlink" the default for all devices. The current default is to slowly truncate files on the local disk.)

[Erik Slagter]

Simpler said (maybe that helps), for all of us that use storage over network, we're not affected by some "slow delete experience" and so we also don't want the workaround for it. So at least make such a workaround configurable. For me unlink() suits just fine.

Edited by Erik Slagter, 24 February 2018 - 17:11.

[MiLo]

Simpler said (maybe that helps), for all of us that use storage over network, we're not affected by some "slow delete experience" and so we also don't want the workaround for it. So at least make such a workaround configurable. For me unlink() suits just fine.

The 'slow delete' option has always been configurable, and the default has always been to only use it for the internal disk.

[Erik Slagter]

But you were suggesting to enable it always - and there's s my objection.

[MiLo]

...What we SHOULD do is make the "slow delete" function no longer the default. Maybe remove it alltogether, ...

I don't see how you could read this as "enable it always".

[Erik Slagter]

Maybe remove it alltogether, .

"It" can refer to either "remove the workaround" or "remove the choice" (as implied by "the default" -> choice).

Edited by Erik Slagter, 28 February 2018 - 21:06.