Human-readable values for data written/read attributes

[jwidess]

This small PR adds a human-readable data size in brackets next to the SMART attributes related to data written/read. This makes it a bit easier to understand the amount of data written/read on a drive and mirrors the format smartctl uses in their reporting as well.

Before:

After:

---

AI Summary:

This pull request enhances the display of SMART attribute values in the device details view by improving how certain storage-related attributes are formatted and shown to users. It introduces human-readable file size formatting for specific ATA and NVMe attributes, and updates the mock device data to include attribute 241 in two places.

Frontend Enhancements:

• Updated the getAttributeValue method in detail.component.ts to display ATA attributes 241 and 242 as both their raw value and a formatted file size using FileSizePipe.
• Enhanced the getAttributeValue method to display NVMe attributes data_units_written and data_units_read as both their value and a formatted file size.
• Imported FileSizePipe in detail.component.ts to support the new formatting logic.

Mock Data Updates:

• Added attribute 241 to the attrs object in two places within the sdb mock device data to ensure consistency with the new display logic. [1] [2]

[kaysond]

@jwidess -

1. Can you please disclose your use of AI on this, per our AI policy
2. It looks like you've hardcoded 512 here but I'm fairly certain the smart attributes (for ATA at least) are in blocks. So it could be 4096 for some drives
3. Please rebase this

[jwidess]

@kaysond 1. Absolutely, I used VS Code Copilot with a Gemini 3 Pro agent for the majority of these changes and to identify where exactly it needed to be implemented. I felt that for the simplicity of this commit, this was easy and acceptable. And I did test this on two separate machines to verify that my changes functioned and displayed correctly.
2. Yes, 512 is hardcoded, that was just the math I copied over from figuring out the conversion on my NVMe drive without thinking about different sector block sizes! I will take a look at addressing this to dynamically use the correct block size dependent on the drive, because otherwise, you are right, this will report a very wrong value for 4096.
Feel free to either close this PR and I will make another once I've implemented and tested that, or give me a few days/weeks to have some time to review that.
3. Done.

[kaysond]

@kaysond 1. Absolutely, I used VS Code Copilot with a Gemini 3 Pro agent for the majority of these changes and to identify where exactly it needed to be implemented. I felt that for the simplicity of this commit, this was easy and acceptable. And I did test this on two separate machines to verify it functioned and displayed correctly. 2. Yes, 512 is hardcoded, that was just the math I copied over from figuring out the conversion on my NVMe drive without thinking about different sector block sizes! I will take a look at addressing this to dynamically use the correct block size dependent on the drive, because otherwise, you are right, this will report a very wrong value for 4096. Feel free to either close this PR and I will make another once I've implemented and tested that, or give me a few days/weeks to have some time to review that. 3. Done.

Thanks. We can leave this one open. Feel free to ping me when you're ready for review