Low on SRAM but doing fine - SD library 512B buffer for reads only?

My question is this: Does the apparent 512 byte buffer used by the SD library only come into play on reads?

I'm using an Uno compatible, 2kB SRAM.

My sketch was running with about 550 bytes free prior to implementing the datalogging, following my attempts at optimization using F() for literal Strings and changing ints to bytes for indexes and values that don't need more than 255, etc. I'm using the LiquidCrystal, OneWire, DallasTemperature and now SD libraries (the built-in one).

I'm using an Adafruit breakout and it's working great... no muss no fuss compared to the $2 eBay versions I gave up on. Lesson learned. Don't waste an afternoon over $5. I did use the official SD utility to format a Transcend 16GB card.

During some research on lowering SRAM requirements I read that the SD library uses a 512 byte buffer but I'm running my sketch without issue, still reporting about 460 bytes free, at least where I'm checking it.

As far as I can tell my datalogging (and the rest of the sketch) is working fine with no missing variables, display issues, etc.

Just roll with it?

In my opinion, this has nothing to do with a buffer in the SD / SdFat library, but with the technical structure of an SD card.

Files are written in blocks. blocks (on sd card's) are the 512 byte large.
To check the size of an sd card u can use SdFatEx (more low level than SD or SdFat):

Sd2Card  sd2Card;
sd2Card.begin(PIN_CS);//SD card CS Pin
uint32_t cardSize = sd2Card.cardSize();//n * 512 byte data blocks
cardSize = cardSize / 2 / 1024;//Blocks -> kb -> mb
Serial.println("Card Size: " + (String)cardSize + " MB");

The reading (sd card reader reads data from the sd card) or writing (sd card reader creates new block + writes data) over more than one block requires more time than read / write within a block.