Frank Steinmetzger wrote: > Am Freitag, 15. November 2024, 06:53:53 Mitteleuropäische Normalzeit schrieb > Dale: >> Rich Freeman wrote: >>> On Thu, Nov 14, 2024 at 6:10 PM Dale <rdalek1...@gmail.com> wrote: >>>> The biggest downside to the large drives available now, even if SMART >>>> tells you a drive is failing, you likely won't have time to copy the >>>> data over to a new drive before it fails. On a 18TB drive, using >>>> pvmove, it can take a long time to move data. >>>> […] >> I think I did some math on this once. I'm not positive on this and it >> could vary depending on system ability of moving data. I think about >> 8TB is as large as you want if you get a 24 hour notice from SMART and >> see that notice fairly quickly to act on. Anything beyond that and you >> may not have enough time to move data, if the data is even good still. > I have 6 TB drives in my NAS, good ol’ WD Reds from before SMR time. When I > scrub them, i.e. read the whole of their data out sequentially at 80 % > capacity (so effectively around 5 TB), it takes 10½ hours. Looks like your > math adds up. Maybe 10 or even 12 TB would also still work in that time > window. Recently I switched from ZFS’s Raid6 to Raid5 because of said 80 % > occupancy and I needed more space, but had neither any free slots left nor > wanted to buy new hardware. Fingers crossed … >
Given the notice could be sent when one is not looking and may not be seen for a while, I'd error on smaller not larger. Some systems could be faster than others as well. Since I use LVM so much, I time pvmove. That is what I would use anyway. If one uses some other tool, it would be good to time with that tool. It could be faster or slower. I suspect the drive would likely be the limit but one needs to test to be sure. >>>> I don't even want to think what it would cost to put >>>> all my 100TBs or so on SSD or NVME drives. WOW!!! >>> # kubectl rook-ceph ceph osd df class ssd >>> ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP >>> META AVAIL %USE VAR PGS STATUS >>> >>> 8 ssd 6.98630 1.00000 7.0 TiB 1.7 TiB 1.7 TiB 63 MiB 3.9 >>> >>> GiB 5.3 TiB 24.66 1.04 179 up >>> […] >> I do wish there was a easy way to make columns work when we copy and >> paste into email. :/ > For special cases like this I think we wouldn’t mind using HTML mail. Or > simply disable automatic wrapping and use long lines of text for the entire > message. The client can then decide where to wrap. > > I know it’s like a religious debate whether to wrap at <80 columns (please > don’t start one here), but there is actually an automatism for this: if you > end the line with a space, you can still wrap you text statically at <80 > columns, but the space tells the client that it may wrap here or not. I > forgot > the name of it though, I learned about it in the mutt user group. > > For me it’s easier: as I use vim in mutt. I usually let it do the wrapping > for > me (including the mechanism I described). But I can disable wrapping on-the- > fly, so I can paste longer terminal output. > >> Dale >> >> :-) :-) I've tried to make things look right before and most of the time, it either gets worse or does something really weird, it double wrapped once. I never sent that double wrapped one but it was weird looking. I have Seamonkey set to convert to text only to anything sent to a @gentoo.org address. Even if I compose it in HTML, it will convert it to text only when sending. I have thought of using screenshots, images. The bad thing there, can't copy and paste it. Plus, some don't like large emails and images can't make one larger than usual. It seems one can't win for losing. LOL Dale :-) :-) P. S. I feel like I am forgetting to mention something. My poor brain. :-(
