72 replies to this topic

[anudanan]

Why is there a spinner when a unlink is in an other thread?

[WanWizard]

If it is a separate thread, it shouldn't be.

 

But the delete is/was/used to be called from the mainloop, if that is no longer the case? It can be tested easily by changing the code to simply do an unlink instead of renaming and going into the callback loop.

[MiLo]

You might consider starting the deletion without renaming them, that way they would instantly become "invisable" (which in itself also has drawbacks).

The "del" files are needed because you want them gone from the movie list. If you delete a bunch of files, they remain around until the deletion thread has gotten rid of them for good. This is independent of whether it just calls "unlink" or if it's slowly deleting them using the truncate method.

 

By renaming them in foreground, the file is at least "gone" when the call returns (because a rename action is very fast). Without ranming first, the file would re-appear in the list if you refreshed it, only to disappear a bit later.

[MiLo]

Why is there a spinner when a unlink is in an other thread?

 

There is no spinner!

 

Only way to get a spinner would be when the main thread is reading the directory and opening a bunch of files, while the background thread (or process, again, that does not matter) is busily deleting stuff. That may cause a bit of stall. But that would happen anyway. It will also happen if you just type some "rm" command on the shell at exactly the right moment.

 

(PS: I/O priority is already being heavily used, but it does not actually have much effect, it makes it enter the queue a bit later but when the IO request has arrived at the disk's queue, the system will have lost the priority information anyway. So even a low prio process can quickly fill the queue and stall all others. Which is probably why it sometimes helps to use a bad scheduler...)

Edited by MiLo, 10 February 2018 - 16:45.

[Erik Slagter]

@Milo an unlink immediately makes a file disappear from the file system (at least from usercode view). But I guess the problem is not that the unlink takes long, but that it occupies the harddisk. If only for the "long" argument, an "unlink" in a seperate thread would suffice.

 

Yet another argument to not install a harddisk in a STB and use an external storage.

[anudanan]

In the past I have seen that EXT2/EXT3 filesystems need a long time to delete big files (and the file is visible by the used for that time) and for journaling reaason in EXT3 it may block some other disk processes. That stalling during unlink  was not happend on EXT2. I´ve used a long time EXT2 instead of EXT3 because I don´t want to block other I processes. I know chkfsk on EXT2 needs much more time as in EXT3 and journaling das advantages.

 

But today with EXT4 the unlink is very quick. For me it is not a problem if the file is for some seconds in the movielist if I delete many big  files in together. 

[WanWizard]

Not everyone will have an ext4 disk.

 

And as Erik mentioned, it isn't only about waiting time, it is also about I/O blocking, which might impact running recordings.

[MiLo]

In the past I have seen that EXT2/EXT3 filesystems need a long time to delete big files (and the file is visible by the used for that time) and for journaling reaason in EXT3 it may block some other disk processes. That stalling during unlink  was not happend on EXT2. I´ve used a long time EXT2 instead of EXT3 because I don´t want to block other I processes. I know chkfsk on EXT2 needs much more time as in EXT3 and journaling das advantages.
 
But today with EXT4 the unlink is very quick. For me it is not a problem if the file is for some seconds in the movielist if I delete many big  files in together.

You can turn off journaling on ext4 if you prefer speed over reliability (in ext3 too, by the way). It will make all disk access, in particular writing and deleting considerably faster. It will also wreck data and cause filesystem errors if the power fails. Your call, this is Linux, you're free to make choices...

Edited by MiLo, 10 February 2018 - 20:34.

[MiLo]

@Milo an unlink immediately makes a file disappear from the file system (at least from usercode view). But I guess the problem is not that the unlink takes long, but that it occupies the harddisk. If only for the "long" argument, an "unlink" in a seperate thread would suffice.

 

Nope. Example:

 

root@et8000:/media/hdd# dd if=/dev/zero of=nothing bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 8.847623 seconds, 56.5MB/s
root@et8000:/media/hdd# touch nada
root@et8000:/media/hdd# time rm nada
real    0m 0.00s
user    0m 0.00s
sys    0m 0.00s
root@et8000:/media/hdd# time rm nothing
real    0m 0.22s
user    0m 0.00s
sys    0m 0.22s
root@et8000:/media/hdd#

 

The "rm" command is just a wrapper around unlink. As you can see, it takes .22 seconds for the unlink to complete for the 0.5GB large file. You definitely don't want to call "unlink" in foreground. Hence the construction with rename and a background thread.

 

A remote disk would only make things slower, as it will wait for the unlink on the other side to complete. There's room for optimization in Linux here...

[MiLo]

What would work is open the file, and then unlink it (the "shrink" code in the background deleter does just that). That causes the actual removal to be postponed, so the unlink would return immediately. The drawback is that this would allocate a file descriptor for each file in the delete queue, and file descriptors are a pretty scarce resource.

[MiLo]

... As you can see, it takes .22 seconds for the unlink to complete for the 0.5GB large file. You definitely don't want to call "unlink" in foreground...

This makes perfect sense, by the way. If you were to do this:

while true
do
  dd if=/dev/zero of=nothing bs=1M count=500
  rm nothing
done

If "unlink" would return before updating the file allocation tables (or whatever the underlying filesystem needs), this loop would eventually error out because it runs out of diskspace. So the contract for the "unlink" call is that on return, the file's data no longer occupies any disk space and can be reclaimed.

[Erik Slagter]

 

In the past I have seen that EXT2/EXT3 filesystems need a long time to delete big files (and the file is visible by the used for that time) and for journaling reaason in EXT3 it may block some other disk processes. That stalling during unlink  was not happend on EXT2. I´ve used a long time EXT2 instead of EXT3 because I don´t want to block other I processes. I know chkfsk on EXT2 needs much more time as in EXT3 and journaling das advantages.
 
But today with EXT4 the unlink is very quick. For me it is not a problem if the file is for some seconds in the movielist if I delete many big  files in together.

You can turn off journaling on ext4 if you prefer speed over reliability (in ext3 too, by the way). It will make all disk access, in particular writing and deleting considerably faster. It will also wreck data and cause filesystem errors if the power fails. Your call, this is Linux, you're free to make choices...

Similarly the way journalling is done. You can choose to have data bypass the journal, which, especially for STB'es, I'd recommend. Having a corrupt file is not nearly as severe as having a completely corrupt file system.

[Erik Slagter]

 

@Milo an unlink immediately makes a file disappear from the file system (at least from usercode view). But I guess the problem is not that the unlink takes long, but that it occupies the harddisk. If only for the "long" argument, an "unlink" in a seperate thread would suffice.

 

Nope. Example:

root@et8000:/media/hdd# dd if=/dev/zero of=nothing bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 8.847623 seconds, 56.5MB/s
root@et8000:/media/hdd# touch nada
root@et8000:/media/hdd# time rm nada
real    0m 0.00s
user    0m 0.00s
sys    0m 0.00s
root@et8000:/media/hdd# time rm nothing
real    0m 0.22s
user    0m 0.00s
sys    0m 0.22s
root@et8000:/media/hdd#

The "rm" command is just a wrapper around unlink. As you can see, it takes .22 seconds for the unlink to complete for the 0.5GB large file. You definitely don't want to call "unlink" in foreground. Hence the construction with rename and a background thread.

 

A remote disk would only make things slower, as it will wait for the unlink on the other side to complete. There's room for optimization in Linux here...

0.22 seconds an issue???

 

BTW I was referring to the file being visible in the filesystem or not. 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. 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.

[Erik Slagter]

What would work is open the file, and then unlink it (the "shrink" code in the background deleter does just that). That causes the actual removal to be postponed, so the unlink would return immediately. The drawback is that this would allocate a file descriptor for each file in the delete queue, and file descriptors are a pretty scarce resource.

Have you tested it?

 

The actual deletion is always carried out by a kernel thread and not the process itself. So the question is whether the kernel makes the thread wait in this case (just like when unlinking). I think it won't matter a bit.

 

How many descriptors do you want? This is no 8 bit microcontroller board... Do you think Linux has any difficulty handling 8k of file descriptors (default max, from the top my head).

Edited by Erik Slagter, 21 February 2018 - 20:29.

[Erik Slagter]

 

... As you can see, it takes .22 seconds for the unlink to complete for the 0.5GB large file. You definitely don't want to call "unlink" in foreground...

This makes perfect sense, by the way. If you were to do this:

while true
do
  dd if=/dev/zero of=nothing bs=1M count=500
  rm nothing
done

If "unlink" would return before updating the file allocation tables (or whatever the underlying filesystem needs), this loop would eventually error out because it runs out of diskspace. So the contract for the "unlink" call is that on return, the file's data no longer occupies any disk space and can be reclaimed.

This behaviour can also be mimiced in a lazy way. Only start blocking the thread as soon as more than x fraction of the blocks are awaiting removal. Bitmap and inode tree btw.

[anudanan]

 

....

0.22 seconds an issue???

 

BTW I was referring to the file being visible in the filesystem or not. 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. 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.

 

 

My uno4kse boxes with openpli 6.1 and an old EMC makes nearly this. Deleting files runs in a separate process. The old EMC creates a shell script which deletes all marked files. I´ve no problems with interrupts of parallel recording movies, and there is no wait actions on the GUI. If the list is very long the user can see a special x-mark ICON on the movies which are in deleting process. That works also in the past with EXT2/EXT3 because deleting runs in background and a user can see in the movielist the X-mark file until the deleting is done.

Edited by anudanan, 21 February 2018 - 20:53.

[Erik Slagter]

And that's not what you'd want. A network connected disk (one way or the other) relieves all these problems, I never have problems with deleting files.

[anudanan]

I have no problems with deleting files

Edited by anudanan, 22 February 2018 - 17:39.

[MiLo]

0.22 seconds an issue???

I merely wanted to demonstrate that the unlink() call is synchronous. Note that it took only 8 seconds to create that file, so that means about 2.5% of the (wall clock) time is spent on administrative work here. That's quite a lot.

[MiLo]

My uno4kse boxes with openpli 6.1 and an old EMC makes nearly this. Deleting files runs in a separate process. The old EMC creates a shell script which deletes all marked files. I´ve no problems with interrupts of parallel recording movies, and there is no wait actions on the GUI. If the list is very long the user can see a special x-mark ICON on the movies which are in deleting process. That works also in the past with EXT2/EXT3 because deleting runs in background and a user can see in the movielist the X-mark file until the deleting is done.

The standard movielist just moves the files to the trashcan folder and they're deleted from that spot in the background. Very efficient as the move operation is instantaneous, and also user friendly since you get a chance to undo the delete if you change your mind.

As for interrupted recordings, this happened on ext3 filesystems with 8 recordings running on a box with a 400MHz CPU. You're bound to have better equipment!