ttsiodras's questions

In our application's configuration, nginx acts as a reverse proxy in front of gunicorn.

Our application replies to frontend requests with generally speaking, small responses... but some endpoints generate responses that are larger than one memory page (4K).

When this happens, nginx logs this warning:

an upstream response is buffered to a temporary file 
/path/to/nginx/proxy_temp/4/86/0000000864 while reading upstream, 
client: 1.2.3.4, server: api.ourdomain.com, request: "GET /pdf/..."

Our nginx logs end up flooded with this warning - and as far as I can see, the only solutions to make this warning vanish from our logs, are bad solutions:

• I can set nginx proxy_max_temp_file_size to 0 - basically disabling the buffering of large-ish responses. This would stop the buffering to files - but it would also mean that for endpoints generating large responses (e.g. PDF-generating ones that create 1-2MB responses) a slow consuming client would stall the corresponding gunicorn worker... In fact, if there are N gunicorn workers, it would only take N clients generating PDFs behind slow network connections, and our application would be down...

• I can increase the proxy_buffer_size to more than 4K (one memory page, that is). I am pretty sure this would have a severe impact in nginx performance - 70% of our responses indeed fit in 4K, and we would force nginx to allocate ... what? 2MB of buffers for each one of them, just to be ready for the occasional PDF-generating request? EDIT: In fact this is not an option at all - Michael (below) commented that the only allowed values are 4K and 8K.

• I could turn proxy_buffering off - but that is just as bad as the first solution (slow clients => death).

In essence, nginx floods our logs about something that we WANT - temporary buffering to files when the responses are big.

We just want to stop this from flooding our logs, by "marking" it as not really a warning (I am not even sure why this is a warning - what "bad thing" is it warning us about?)

Other than editing nginx's source code and recompiling, is there any other solution that I am missing?

When a SMART check on a disk reports a bad sector, it is important to be able to identify the file that has the bad sector - and restore it from backups. Below, I show how I did this for my Linux/ext3 VMWARE server - but does anyone know if this can be done for Windows/NTFS?

Here's how I did it for Linux/ext3: I first asked the drive to do a hardware surface scan (below the OS level, with the on-drive SMART circuits):

vserver:~# smartctl -t long /dev/sdc

I looked at the results:

vserver:~# smartctl -a /dev/sdc
...
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       1
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       9
...
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     27679         591363172

So, one sector was already marked bad, 9 were marked for replacing from the "staging" sector space. More importantly, the first logical block address (LBA) that is unreadable, was 591363172.

I found the partition (and the offset inside it) that this number "translated" to:

vserver:~# fdisk -lu /dev/sdc
Device Boot      Start         End      Blocks   Id  System
/dev/sdc1           32   976773119   488386544   83  Linux

The partition started at sector 32. So, the bad sector was...

vserver:~# bc -l
591363172-32+1
591363141

...at an offset of 591363141 sectors from the beginning of the partition.

Now I could find which file was "hosed":

vserver:~# tune2fs -l /dev/sdc1 | grep Block\ size
Block size:               4096

The block size of this EXT3 filesystem was 4096 bytes, so the bad sector destroyed this block in the filesystem:

vserver:~# bc -l
591363141*512/4096
73920392.62500000000000000000

And the block number (73920392) corresponded into this file:

vserver:~# debugfs
debugfs 1.41.3 (12-Oct-2008)
debugfs:  open /dev/sdc1
testb 73920392
debugfs:  testb 73920392
Block 73920392 marked in use
debugfs:  icheck 73920392
Block           Inode number
73920392        18472967
debugfs:  ncheck 18472967
Inode           Pathname
18472967        /path/to/filewithbadsector

And I restored that file from my backups.

Is there an equivalent procedure I can follow for Windows/NTFS?

For a couple of years, I maintained a "mirror" of my blog (hosted in my old account) on a free page hosted in Googlepages. Over the years, people started using links to that mirror instead of the primary site - and the Google bot learned about it, thus replying to queries with URLs that point to the ttsiodras.googlepages.com domain.

After a couple of years, Google announced it would migrate Googlepages to Google Sites, where people wouldn't be able to write their HTML/CSS/JS, and instead would use on online editor. I had no desire to spend any effort doing that, so I just (a) setup the redirection offered by Google, from the old URLs (ttsiodras.googlepages.com/whatever) to the new Google Sites page (https://sites.google.com/site/ttsiodras) and (b) had that Google Sites page contain direct links to my main page.

And it worked fine. Until now - or at least, until recently.

I checked yesterday, and found out that URLs to my old site (ttsiodras.googlepages.com) are now getting 404s, and are not redirected to Google Sites.

Did something change, recently, in the way these redirects work? Note that I checked some other googlepages links (not of my old site, of other peoples) and it appears they work.

Or was the redirection a temporary service offered by Google? (if so, I can't understand why - the resources involved in this are surely trivial for someone like Google).

Any hints/suggestions most welcome.