> Maybe a small recordsize can have some benefits when overwriting parts of the files...mmmhhh...? Right. People who've done more testing than me reckon on 16K

> Maybe a small recordsize can have some benefits when overwriting parts of the files...mmmhhh...? Right. People who've done more testing than me reckon on 16KB being a good record size for transaction-processing database work, where tables are seeing lots of small inserts and updates. (You might think matching the database's block size would be ideal, e.g. Postgres writes 8KB at a time, but the rationale here is that you tend to get better compression at 16KB recordsize than 8KB, and the benefit from this outweights the write-amplification.) But if database update performance isn't a big deal for you then you can probably just ignore this. I've not done any testing of my own at the 1MB size, but I don't think I'd be inclined to try it unless I was fairly confident that there weren't going to be many small writes to big files. In short: use the large recordsize where you think you've got a good case for it, and likewise with a small record size. Otherwise, just stick with the default.