I too am interested, and decided to ask a couple of AI agents this: Can constant blinking of hdd led be caused by using xfs .
The output on all 4 cases was pretty much the same:
Yes, constant blinking of your HDD LED can be directly caused by using the XFS filesystem, primarily due to its automated, periodic background logging and metadata management processes.
By design, XFS works hard to prevent data loss and filesystem corruption. It achieves this by maintaining an internal log and grouping storage metadata into âAllocation Groups.â If your system is idling but the HDD activity light is flashing rhythmically (often every few seconds), it is usually due to the following file-system level behaviors:
Persistent Log Flushing (xfssyncd)
XFS uses a background daemon to guarantee metadata integrity.
The Cause: By default, XFS automatically flushes its internal log and metadata buffers to the physical disk every 30 seconds.
The LED Impact: This periodic âsyncâ triggers brief write operations, causing the LED to flash rhythmically even when you are not actively reading or writing files. [1]
Space Management & Discard Operations (fstrim)
XFS relies heavily on automated block and space allocation cleanup routines.
The Cause: If your system has fstrim.timer enabled or XFS is mounted with the discard option, the system frequently issues commands to clear out unused blocks. [1]
The LED Impact: On solid-state or thin-provisioned drives, continuous background block trimming causes constant disk controller communication.
Active File System Buffering
Unlike filesystems like ext4, which can delay block allocations long after a file is initially modified, XFS aggressively manages its allocation groups. Any minor application write (such as a system log or a browser caching a background page) forces XFS to update its internal structures across its allocation groups, waking up the physical drive lines. [1]
Then I suddenly remembered that you have nofail for your big xfs filesystem. So I searched a bit further and this could be the culprit. In your fstab change the nofail to defaults, noatime reboot and see what that does to the blinking rhythm
I tested this but no change in blinking. But then again, physically removing the drive had no effect either.
/home is xfs too, but has defaults in fstab
Thatâs what I refer to as a targeted question ⌠which almost any AI tool will answer in the positive. Thatâs why I never trust any AI output for the past 20+ years.
And for fun, I thought Iâd ask a much more proper question, leaving out âwhichâ filesystem ⌠but to let the AI tool answer âwhichâ filesystems are notorious.
Guess what ⌠XFS was never mentioned. Hereâs the brief answer of the named filesystems, from #1 down:
BTRFS
ZFS
NTFS
EXT4
Hereâs my non-influencing question:
âCan constant blinking of hdd led be caused by which filesystemâ
Long-winded response, from AI:
Yes, the constant blinking of an HDD LED can be caused by specific filesystems, primarily due to features like journaling, copy-on-write (CoW) mechanisms, metadata indexing, and aggressive cache flushing.
While any filesystem will flash the LED during active use, the filesystems listed below are notorious for causing continuous, rhythmic, or heavy background blinking even when your computer seems completely idle.
BTRFS (Linux)
The Cause: Btrfs is a modern Copy-on-Write (CoW) filesystem. It constantly runs background operations such as transaction commits, metadata synchronization, and automated file system scrubbing.
The LED Behavior: You will see a rhythmic, rapid blinking every few seconds as it writes âBtrfs transactionsâ and metadata updates to the disk to ensure data integrity.
ZFS (Linux, FreeBSD, TrueNAS)
The Cause: Like Btrfs, ZFS relies heavily on Copy-on-Write. By default, ZFS accumulates data in system RAM and flushes it to the physical disk in Transaction Groups (TXGs) every 5 seconds.
The LED Behavior: A very distinct, heavy pulse or burst of blinking exactly every 5 seconds, even if you are not actively saving any files.
NTFS (Windows)
The Cause: NTFS utilizes a metadata journal ($LogFile and $UsnJrnl) to keep track of changes. Furthermore, Windows deeply integrates NTFS with background features like Windows Search Indexing and SuperFetch/SysMain, which constantly read file metadata to optimize the OS.
The LED Behavior: Constant, light, erratic flickering when idle. If it is a new Windows install or you recently added many files, it will flash intensely for hours while indexing.
Ext4 (Linux)
The Cause: Ext4 uses an internal journaling mechanism (jbd2) to prevent data corruption. Linux also features a background process (dirty_writeback_centisecs) that forces cached data out to the drive every 5 seconds by default.
The LED Behavior: A steady, predictable blink every 4 to 5 seconds as the jbd2 kernel thread updates the filesystem journal.
Is it a problem?
Most of the time, no. It means the filesystem is doing its job to protect your data against corruption from sudden power loss.
However, if you want to verify that it is just normal filesystem activity and not malware or a failing drive, you can check using built-in operating system tools:
On Windows: Open Task Manager (Ctrl+Shift+Esc), go to the Performance tab, click Open Resource Monitor, and check the Disk section to see exactly what files are being written to.
On Linux: Run the command sudo iotop -o in your terminal. This will filter out everything else and show you the exact filesystem thread (like jbd2 or btrfs-transaction) causing the LED to flash.
I donât give a <word_here>. And changing my prompt does clearly not improve the search. Nor does it help the OP, it rather makes the thread more confusing.
Do you have KDE Frameworks 6.29 and do you use kwallet with Close Behavoir â âWhen unsued for:â (KDE Wallet â Wallet Preferences â Close Behavoir â âWhen unsued for:â)?
kwalletd writes then 1.000 error lines per second into the journal/log files instead 1 per minute.
Will be fixed in KDE Frameworks 6.30.
Workaround: Deactivate Close Behavoir â âWhen unsued for:â
(KDE Wallet â Wallet Preferences â Close Behavoir â âWhen unsued for:â).