pwm

I think the optimum would be if ControlR or similar would support handing over parts of the required secret - so the phone could be used to manually enter a partial sign-on to acknowledge the startup of the server. A bit similar to how you use phone apps when doing two-factor login to banks etc. I'm not worrying about any police - but I'm constantly wary of the almost infinite number of security holes constantly being found, and I don't want some two-bit hacker being able to retrieve full key material just by a bit of luck and some hole in some software module. And it's too easy to sneak in keyboard loggers. The only way to ever get reasonable security is by designing systems with multi-factor login - it's way harder for someone to be able to listen to both a PC keyboard and a mobile phone.

When the end users are allowed to configure how much RAM to allocate to different additional features, it's impossible for LT to make a system where the users can't run out of RAM. And with the root FS in RAM, the only way to stop people from running out of RAM by writing to the root FS is to limit the size of the root FS - but while that stops people from consuming all RAM, it doesn't solve the issue with a full root FS and all the problems that leads to. In the end, it's impossible to make an idiot proof system - nothing is foolproof to a sufficiently talented fool.

Notice that I did write 1.5 for SATA-type connector pins. Each pin can handle 1.5A, but the SATA connector has three pins for each voltage so it can handle 4.5 amp for each voltage. With splitter cables, you can keep down the current/connector pin at the drive side. But you still have high currents on the PSU side of the cables, i.e. before the split. When you run a high current through a connector, the connector gets hot. When it gets hot, it increases the problems with corrosion. And corrosion increases the contact resistance which means more losses and more heat. Next thing is that a high load over some few cables means lots of voltage loss - and because computer equipment is constantly varying the load, there will be constantly varying voltage losses. So the disks will see less stable voltages and the filter capacitors will have to work harder. So you do not want to feed 15 disks from a single cable out of the PSU.

One SATA cable to power 15 disks? That's a truly huge startup current to handle. With 2 A startup current, it's 30 amps to handle during startup. In general, you should avoid going over 8A / connector pin for Molex-type connectors. Each contact pin can handle up to 11 A but the cables used are normally dimensioned for 6-10 A. And avoid going over 1.5A / connector for SATA-type connector pins.

A Bluetooth beacon works quite well, since it's usable on both laptop and desktop machines - it's easy to add a USB receiver for machines that hasn't BT built in. Right now, I can have my Linux machines lock down if I walk outside range with phone or headset. And with a fixed BT beacon at home/office, a laptop that is moved outside the range of the beacon will lock down. I haven't figured out how to get the same functionality on my Windows machines yet. The advantage with BT is that I can walk around to a neighbor room with a laptop without it activating the lock screen.

Could work, but not easily. If you use IR movement sensors and have a glass side panel, you are likely to trig it yourself. And if you haven't, then the IR detector wouldn't notice anything until you open the case. So it would then have to be some kind of orientation/vibration sensor that detects that the case is lifted up. Mercury switches are easy to use, but forbidden in most parts of the world. So next step then would be either switches with a rolling ball, or stepping up to semiconductor sensors - 3D compass or 3D accelerometers or similar. But it would still take a bit of work to make the sensor trig if the computer is carried away but not trig if you just want to dust the machine or replace a HDD.

I have been moving servers between rooms using this trick. Very useful to have redundant PSU on machines. Next step up in security is to have the machine geo-locked - have it listen for BluTooth, WiFi or similar and unmount if the geofence test fails.

The important thing here is that if enterprise disks have an annual failure rate of 0.5% and desktop drives an annual failure rate of 3%, it normally still cheaper to buy desktop drives - assuming that the user has a backup strategy that can handle drive failures without data loss. If we assume that the economical life span is 5 years, then 2,5% of enterprise drives would have failed after 5 years, and 15% of desktop drives (I'm assuming broken drives gets replaced so the formula would be 5*0.03 and not 1-0.97^5). But 15% failure after 5 years still doesn't represent so much money compared to the premium prices of the enterprise drives. And this is one of the reasons why BackBlaze is fine with desktop drives - their storage model has enough redundancy that they can handle failures and 15% lost drives after 5 years is still much less money than what they would gain from having a 5-year warranty with enterprise disks. The video puts too much focus on the value of a 5 year warranty and that the buyer should base the disk choice on purchase price per warranty-years. For a user that ignores backup and only trusts in the parity drive, I would definitely recommend high-end drives with less probability of failures. But since even enterprise disks fails sometimes, it really isn't a recommended route go enterprise disks and ignore backup. A user with triple backup needs really huge amounts of bad luck to not be able to recover if a desktop-class drive in the main server happens to fail.

I have lost a number of blue WD and Seagate desktop drives over the years - both 2.5" and 3.5" drives. I have often used two 2.5" in mirror for system and two 2.5" in mirror for often accessed data and then a number of - at the time of installation - large 3.5" drives for mass storage. I'm not sure if it's the 24x7 use or if it's vibrations. I have a number of WD green, but they have normally only been used together with one SSD or 2.5" system disk - no failures yet. And still no single-disk 2.5" failure - every 2.5" disk that has failed has been in a mirror pair and the 2.5" drives have normally been mounted without any rubber grommets. All manufacturers claims only NAS or enterprise drives should be used in multi-disk installations. I have 3-digit number of disks online but that is still too little to get any really good statistics from. But I get a feeling that the claims about better handling of vibrations in the NAS disks really is an important factor. Both in the improved mounting of the platters and the vibration sensors that makes the disk pause writes if it detects vibrations. Somehow, it would be good to have a normalized test bench, where we can measure amount of disk vibrations using different disks and using different disk cages and/or cases.

It's very hard with temperatures, because you need to know what offset and/or scale you need to configure for the different inputs to get them to translate the raw measurement into an actual temperature. Best would be if you could find someone else with same motherboard and a posted configuration file that contains the configuration values for the nct6791 sensor. I wish the motherboard manufacturers could have been nice and post these translation figures to make it easy for Linux users to measure temperatures and voltages instead of having to depend on the manufacturers often Windows-only tools.

It's good that it's flooding your mail - the very clear message to you is that you need to do something to solve the original problem. You still have issues with controllers and/or disks and/or cables and/or the PSU - and the SMART data keeps ticking up because it isn't a problem that is safe to ignore. When the counter ticks up, you can be lucky that the drive caught the transfer error - the scary thing is that some transfers may contain errors that the drive doesn't pick up. That means you read out - or write down - incorrect data.

Yes, it's global, as I mentioned in my post. The other option is to use Google to search on this site. Google search is good enough that it doesn't matter very much if Google has to search on all forum content.

This link allows search. But no selection on subforum. https://lime-technology.com/search

With the BTRFS fixes introduced about a year ago in the kernel, I find single-disk BTRFS work very well. I have a couple of thousand installations in automotive environment with BTRFS that have worked very well. But before the kernel fixes, single-disk BTRFS was very unstable - after an unexpected power loss you really couldn't trust it to come up to a stable state. Given the time LT spends picking up kernel patches, I would assume current unRAID versions has all BTRFS fixes. I'm not sure if multi-disk BTRFS has also reached a reasonably stable state. There are quite a lot of people who seems to have issues with their multidisk caches. The RAID5/RAID6 support in BTRFS is most definitely not commercial grade.

First step is a tool that finds duplicates on content - so some tool that computes a hash for every file and then sorts the hashes and reports duplicates. If they have same name/path but different disk then it should be safe to remove. If they have different name then you need to consider if any specific program (such as Plex or other media player) may have remembered the path+name. As a second step you can use a tool that searches for same path/name. And because of the first pass removing files with identical binary content you now know that you need to look at the actual content and change date of the files to decide which to keep.

Background computations would be nice and optionally a field showing when the last result was computed so the user can decide if it's good enough or if it would be meaningfull to request a recomputation. I don't think the current computations will show better results if there are ongoing file updates - any code that traverses a directory tree will miss changes performed in the parts of the tree that has already been traversed. The only way to catch all is to capture all file write operations to compute how that changes the total. When there is only one share on a partition, then some file systems allows the disk use value to be picked up and used for free.

When you "give" disks to a disk array, it's the array that owns the disk. Never play with that disk outside the control of the array management system unless you really, really do know what you do - it's only safe to do a read-only mount of an array disk outside of the array. A normal mount will introduce writes to the disk - there are multiple reasons but one important reason is so an incorrect power-down will leave a marker on the disk about an unclean shutdown indicating that the next time the disk is mounted the file system layer has to look at pending writes in the journal on the disk and either replay them or roll back them. So taking an unRAID array disk and mounting it in normal read/write mode outside of the array means the write commands introduced when mounting the disk will create parity mismatches. Which means the system can't do a clean disk rebuild in case a drive fails. And the writes introduced when mounting one file system can result in very damaging rebuild errors for file systems on other disks.

Yes, it's a fun project. It also makes sure my unRAID machines don't get too bored since they are part of the storage pool - committed files are normally sent to multiple storage pools for redundancy. But you did catch me with the NFS handle size. I think the physical files still just about fits in 32-bit numbers but virtual views are created using inode values way outside the 32-bit range. A lot can be said about NFS security. Especially since most equipment runs NFSv3 that is limited to host-based authentication. But it works quite well for read-only access to media files.

Yes, I place the DB record ID into the st_ino field before handing over to the FUSE code. I have used it too little with NFS shares - most browsing is either done using SMB (with the FUSE VFS running on the storage server), or I run a copy of the FUSE VFS on the client machine and stream the actual file data over a TLS-encrypted tunnel from the storage server. I should really set up a dedicated test system stressing NFS - especially since the VFS also includes all my media files and could present suitable movie or music selections to media players. I already know my older Popcorn Hour and QNAP media players works much better with NFS than SMB for some movie titles. One important difference here compared to shfs in unRAID is that my VFS only allows viewing of archived file data - i.e. read-only access. Writes to the storage server happens by having a backup client scan a directory tree and "check in" changes to the storage pool. But this doesn't involve any FUSE code. The VFS code can just get a notification that more file data has been "committed" to the storage server so it can check if more and/or changed files should be made visible in the presented VFS.

Yes. For simpler things - like presenting individual streams of a BD image - i use the high-level interface. But the VFS for the backup server solution is using the low-level interface and hands over the database record ID as inode to FUSE. But I haven't found much information about how FUSE itself handles inodes - they have their own inode field in their structures but seems to always duplicate the inode value I supplied.

Yes, one reason why I asked was specifically thinking about that memory leak thread. I have developed some own FUSE applications but they supply inode values from a database (since they work as "time machine" and can present arbitrary disk snapshots based on backup times). But since my FUSE code will always supply the same inode for each presented file I haven't seen any issue with leaked memory even if the database contains many hundred million files.

Just a quick question - does shfs keep static inode allocations until reboot or is fuse allowed to reuse inode allocations? Inode reuse is an issue for NFS shares.

Accessing the unRAID directly from Internet is like sending out a lamb into the woods knowing a pack of very hungry wolves lives there. The two reasonably safe options is to use a VPN solution or to use something like sshfs to tunnel file accesses over a ssh tunnel. But any safe way to share files requires the use of a strongly encrypted tunnel or someone will have your unRAID for dinner.

Yes, I know about the cache pool. But that's just a single additional mirror. My main storage server is currently running 3 separate mirrors besides the main disk array. And I plan to add a fourth mirror and possibly a second full disk array when I continue to throw in more disks. The only way I can merge unRAID with the other functionality is if I run unRAID virtualized to handle a single array in the main server. Many separate mirrors means I can get huge, disk read/write speeds to keep a 10Gbit/s network happy streaming media concurrently with making larger backups. So currently, I have multiple unRAID for secondary tier storage pools. Which also means I can't take full advantage of the Docker/VM support in unRAID because all the nice SSD mirrors are on the main server.

Just an addendum. While enterprise disks can perform at optimum speed without trim, they can still take advantage of trim to reduce the write amplification. If a 128 kB flash block contains 64 kB erased data and 64 kB current data and the OS wants to rewrite the 64 kB of current data then the disk has two options - if the 64 kB erased data has been reported through trim, then the drive can erase all content on that flash block while finding a suitable flash block for the new 64 kB write. So 64 kB of file writes results in 64 kB of flash writes. - if the 64 kB erased data hasn't been reported, then the drive will pick a suitable spot for the 64 kB write. Then it will still think 64 kB data is valid on the original block. So when it later decides to erase that flash block, it first has to copy 64 kB to another block. So a single 64 kB file write results in 64 + 64 kB of flash writes. So without the trim, there was a larger write amplification. Another thing to consider here is that unRAID, like SnapRAID, doesn't stripe. So with 4+1 system with a traditional striped RAID 5, a 1 TB file write will result in 1.25 TB of flash writes since the parity adds 25% additional surface. With unRAID, a 1 TB file write means the parity drive also has to handle a 1 TB write - so in total 2 TB of SSD writes. In a traditional RAID 5, all drives gets the same amount of wear. You can select enterprise or normal drives depending on amount of writes the system needs to handle. In unRAID, the parity drives would need to be expensive enterprise drives to be able to handle the additional number of TB of writes. Or the user would have to replace the parity drives 5-10 times more often depending on number of data disks. One strong part about unRAID is that the unstriped data means only needed HDD has to be spinning. This is excellent for media consumers. With SSD this doesn't really matter because they don't produce noise and consume as much power which means that one of the unRAID advantages would no longer hold true. unRAID would still have a big advantage that each drive holds a valid file system so you can't get a 100% data loss because you lost one drive more than the number of parity drives. In the end, I think it would be better if unRAID could add support for multiple arrays - mixed freely between unRAID arrays and normal RAID-0, RAID-1, RAID-5, ... than to focus on running a strict SSD main array. Especially if unRAID could still merge multiple arrays into unified user shares. That would allow people to select two-disc SSD RAID-1 for applications and special data while keeping the huge bulk data on much cheaper HDD.