Javier Martinez wrote: > El 7/10/25 a las 20:25, Dale escribió: >> Javier Martinez wrote: >>> El 7/10/25 a las 17:37, Dale escribió: >>>> Javier Martinez wrote: >>>>> El 7/10/25 a las 16:04, Dale escribió: >>>>>> Howdy, >>>>>> >>>>>> As most everyone knows, I have some large file systems here. Mostly >>>>>> videos. These are encrypted until I open/unlock them. So, when I >>>>>> am on >>>>>> those rare occasions booting up, there's no way to run fsck on them >>>>>> automatically. I basically have two questions on this. 1: How >>>>>> often >>>>>> should I open but not mount the file system and run fsck on it? >>>>>> Once a >>>>>> month, two months, six months, a year or what. 2: Also, what is a >>>>>> command that you use that will fix most things without asking a >>>>>> lot of >>>>>> questions but not do anything that will damage or potentially >>>>>> damage a >>>>>> file? Basically, what command would you use for a situation like >>>>>> this? >>>>>> The man page shows a option for all 'yes' but there may be times >>>>>> when >>>>>> 'yes' isn't a good idea. I'm wondering if someone has came up >>>>>> with a >>>>>> way to handle this with some option I'm not aware of. >>>>>> >>>>>> Right now I use the command e2fsck -pf /dev/mapper/<mount point >>>>>> here> to >>>>>> check it but it ignores some things that it would usually fix if I >>>>>> were >>>>>> being asked first. Something about things could be smaller. It's >>>>>> usually a LOT of them. I'd like those to be corrected as well. >>>>>> Maybe >>>>>> running the check twice with different options will fix it all???? >>>>>> >>>>>> Current info. >>>>>> >>>>>> >>>>>> FILESYSTEM (=) USED >>>>>> FREE (-) %USED USED AVAILABLE TOTAL MOUNTED ON >>>>>> /dev/mapper/crypt >>>>>> [==========================================--------] 83.8% 39.5T >>>>>> 7.6T 47.1T /home/dale/Desktop/Crypt >>>>>> /dev/mapper/data >>>>>> [==============================================----] 91.7% 43.2T >>>>>> 3.9T 47.1T /home/dale/Desktop/Data >>>>>> >>>>>> >>>>>> I'm thinking about adding a 18 or 20TB drive to data. I got a >>>>>> empty one >>>>>> in my safe as a spare. May need to buy a couple more drives soon. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Dale >>>>>> >>>>>> :-) :-) >>>>>> >>>>> >>>>> You can make one script involving cryptsetup and fsck. Or you can add >>>>> one passfile to the luks volume add it to the crypttab and to the >>>>> fstab to auto unlock at booting and check it. >>>>> >>>>> I suggest you that you make the check every time you are going to >>>>> mount your disk before doing it. If the filesystem has some kind of >>>>> error could be problematic. If its in healthy state, it will not >>>>> spend >>>>> time, >>>>> >>>>> Maybe you can use "-E no_optimize_extents" option in e2fsck if the >>>>> message that is boring you is related with extents optimization. >>>> >>>> I had actually thought about including the check in my open script. >>>> It's the little script I made to open and mount the file system. I >>>> don't want to use anything that opens the file systems >>>> automatically. I >>>> open and close them manually as needed. >>>> >>>> The one I get the most is something like this. >>>> >>>> >>>> Inode 761564625 extent tree (at level 1) could be shorter. Optimize? >>>> yes >>>> >>>> >>>> Sometimes it says narrower instead of shorter. There are hundreds of >>>> them but after a few, it gives me a "a" option to say 'yes to all' of >>>> those types of questions. The thing I don't like about the -p option, >>>> it seems to only run certain tests but also ignores some things >>>> that it >>>> might be best to correct as well. When I leave off the -p option, it >>>> takes longer but it does more testing. Tests it doesn't do with >>>> the -p >>>> option. I want it to be thorough in the testing but I also would like >>>> it to fix what it can without me typing in "y" for each one, or >>>> quite a >>>> few of them before giving me a yes to all option. >>>> >>>> I figure someone on this list has ran into this problem and found a >>>> really good solution. I'm just hoping someone will share. LOL ;-) >>>> >>>> Dale >>>> >>>> :-) :-) >>>> >>> The option no_optimize_extents or even fixes_only should make this >>> questions go away even in /etc/e2fsck.conf, I would not use -y option, >>> -n instead to answer all no. Also you can use -z undo_file to allow >>> restoring if fsck makes one mistake >>> >>> I suggest you that you use -ck periodically in case that your harddisk >>> start having faulty sectors. You can use tune2fs -c flag to force a >>> check between mounts or use -i to force a complete check between >>> periods of time >>> >>> So, in resume, always make a fsck check before mount to see if its in >>> a clean state or not. >>> >>> Use tune2fs to force a check periodically between mounts or time >>> passed even if it seems clean. >>> >>> If you don't want to take care of extents optimizations, you can set >>> options sent before in /etc/e2fsck.conf >>> >>> I would never use "-y" option in fsck. >>> >>> If you want to get fsck into the script you should check fsck error >>> codes before mounting the volume, so $? is your friend. >>> >>> 0 - No errors >>> 1 - File system errors corrected >>> 2 - File system errors corrected, system should >>> be rebooted >>> 4 - File system errors left uncorrected >>> 8 - Operational error >>> 16 - Usage or syntax error >>> 32 - E2fsck canceled by user request >>> 128 - Shared library error >>> >>> If not 0 or 1 don't try to mount it. >> >> >> This is one reason I'm thinking about putting it in my script so it does >> it each time. When I leave home, I always close my encrypted file >> systems. When I get back home, I open them again. I usually go to town >> once a week, standing Doctor office visit and gotta have groceries. So, >> I do unmount once a week at least. Thing is, a lot can go on during >> that week. Some weeks the amount of data that changes can be fairly >> large. Some weeks, not much at all. I just want to figure out if it is >> something I should just do manually every once in a while or include in >> my script, just to be sure. >> >> I read up on the -y option a while back. I don't plan to use that. >> From what I've read, most of the time it is fine but it can think it is >> fixing something when it is actually not. I've read where some in >> certain cases lost data using that. I don't mind it making things >> shorter or narrower. Those seem to be normal fixes. Thing is, with the >> -p option, it ignores that and seems to not run all the tests. Without >> -p it seems to do a lot more. I figure I need a better set of options >> to get the check done right without it asking me a lot. That way, I can >> put it in a script as well. >> >> I read the man page and the -ck options may require some more reading. >> Most of the time, man pages don't make sense to me. I have to find >> better explanations that make more sense. It sounds like it does more >> checking and updating of bad blocks. That's as far as I got so far but >> sounds like a good idea. >> >> I'm familiar with $?. I'm not sure how to make it check for two outputs >> tho. Right now, want to find out the manual way. Then move it to a >> script. >> >> Making progress. >> >> Dale >> >> :-) :-) >> > You can open also in a new mount namespace with unshare...., although > somebody could enter with nsenter (require being root). > So -ck is read only test, -cck is non destructive read write test, the > later, dont use in ssds.
I read about using -cc and it doing something different but wasn't 100% sure what. Your post makes sense. Single c, read only, double c means it can write. I didn't see anything about not using on SSDs tho. Thanks for that tidbit. I have a couple of those now, 4 or 5 actually now that I think about it. I was in the woods trying to change trail camera batteries and memory cards. Before I left the house, I checked the radar. No rain anywhere near me. After changing two cameras, bottom fell out. I had to go duck under a shooting house. Now I'm wet, back home and it stopped raining. ROFL I bet if I walk back out there, it will rain again. My greens could use some rain so I just may do it. I'm kinda wet now anyway. :/ Dale :-) :-)
