What functions interfere with EEPROM read/write?

I have used the EEPROMAnything library on many projects and had no problem saving relatively large blocks of data encapsulated in a struct.

On my current project I am having nothing but problems with EEPROM read/write. Just bizarre unpredictable results where data is only being stored properly in some areas and other areas of eeprom return corrupted values and it is totally inconsistent.

This current project uses several timer ISRs and I was wondering if there are caveats to using EEPROM such as disabling/enabling certain interrupts?

What else could possibly interfere with how read/write to eeprom works?

I am using an Atmega328-PU and the amount of data I am trying to store is relatively small (definitely less than 1k).

After writing to EEPROM immediately entering the sleep mode could be a problem.

and had no problem saving relatively large blocks of data encapsulated in a struct.

Have you gone back to earlier projects and checked if the EEPROM is still working. There is a limit on the number of write cycles it can take, you might have exceeded that.

Interrupts should be disabled during EEPROM writes, so nothing should be interfering with it.

I suggest writing a small sketch to test your EEPROM. Write known values and patterns to each cell and see if they read back OK - it could be that your EEPROM has reached the end of its lifetime - how much have you used it?

For instance, fill the whole EEPROM with 0x55 and test it, then fill it with 0xAA and test it. If you're feeling adventurous you could try each of 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40 and 0x80 too. Also an alternating pattern of 0x55 and 0xAA is good to try (address 0 = 0x55, address 1 = 0xAA, address 2 = 0x55, address 3 = 0xAA etc).

Another thing springs to mind - which chip are you actually using? Some have less EEPROM than others.

And EEPROM writing requires a stable power supply - if Vcc is dipping during writes it could cause unreliable results.

Suggest you post a minimal sketch which demonstrates the problem, for example by writing a sequence of hard-coded values to the EEPROM and displaying the values read back. It may be a hardware problem, but it may simply be a problem with your code.