To my understanding, it makes no sense to perform a TRIM on storageYes. Generally speaking, all file systems know exactly whats in use,
which is a LUKS2 encyrypted LVM. The storage device should anyway
think that each bit is in use after it was filled with random data
when creating the space. Not only that I cannot imagine how the
storage device should Know what is happening in the encrypted space,
wouldn't it be a security issue if the OS would inform the storage
device about unused space and its location and could actually perform
some kind of a TRIM?
Am I wrong?
If I am right, then, and assuming that TRIM is done by a command
called fstrim, is there a simple command by which I could search
through all cron entries if fstrim would somewhere be defined to
become executed?
.
On 2/20/25 14:10, Marco Möller wrote:
To my understanding, it makes no sense to perform a TRIM on storageYes. Generally speaking, all file systems know exactly whats in use,
which is a LUKS2 encyrypted LVM. The storage device should anyway
think that each bit is in use after it was filled with random data
when creating the space. Not only that I cannot imagine how the
storage device should Know what is happening in the encrypted space,
wouldn't it be a security issue if the OS would inform the storage
device about unused space and its location and could actually perform
some kind of a TRIM?
Am I wrong?
they have to, otherwise they would randomly overwrite another file, The encryption is only for the data in that allocated space. The file system knows nothing about that data
If I am right, then, and assuming that TRIM is done by a command
called fstrim, is there a simple command by which I could search
through all cron entries if fstrim would somewhere be defined to
become executed?
.
Cheers, Gene Heskett, CET.
On 2/20/25 20:48, gene heskett wrote:
On 2/20/25 14:10, Marco Möller wrote:
To my understanding, it makes no sense to perform a TRIM on storageYes. Generally speaking, all file systems know exactly whats in use,
which is a LUKS2 encyrypted LVM. The storage device should anyway
think that each bit is in use after it was filled with random data
when creating the space. Not only that I cannot imagine how the
storage device should Know what is happening in the encrypted space,
wouldn't it be a security issue if the OS would inform the storage
device about unused space and its location and could actually
perform some kind of a TRIM?
Am I wrong?
they have to, otherwise they would randomly overwrite another file,
The encryption is only for the data in that allocated space. The file
system knows nothing about that data
If I am right, then, and assuming that TRIM is done by a command
called fstrim, is there a simple command by which I could search
through all cron entries if fstrim would somewhere be defined to
become executed?
.
Cheers, Gene Heskett, CET.
So, the other way round, having a LUKS2 partition and then LVM in it,
that would be the one where TRIM wouldn't make sense? But would be
safer in terms of "hiding" data from spying eyes?
.
Generally speaking, all file systems know exactly whats in use,
they have to, otherwise they would randomly overwrite another file,
The encryption is only for the data in that allocated space. The file
system knows nothing about that data
On 2/20/25 14:10, Marco Möller wrote:
To my understanding, it makes no sense to perform a TRIM on storage
which is a LUKS2 encyrypted LVM. The storage device should anyway think that each bit is in use after it was filled with random data when
creating the space. Not only that I cannot imagine how the storage
device should Know what is happening in the encrypted space, wouldn't it
be a security issue if the OS would inform the storage device about
unused space and its location and could actually perform some kind of a TRIM?
Am I wrong?Yes. Generally speaking, all file systems know exactly whats in use, they have to, otherwise they would randomly overwrite another file [...]
encryption is only for the data in that allocated space. The file system knows nothing about that data
On Thu, Feb 20, 2025 at 02:48:21PM -0500, gene heskett wrote:As I said, I know zip about LUKS. If LUKS replaces the file system
On 2/20/25 14:10, Marco Möller wrote:You are wrong here, Gene -- in a strangely indirect way.
To my understanding, it makes no sense to perform a TRIM on storageYes. Generally speaking, all file systems know exactly whats in use, they
which is a LUKS2 encyrypted LVM. The storage device should anyway think
that each bit is in use after it was filled with random data when
creating the space. Not only that I cannot imagine how the storage
device should Know what is happening in the encrypted space, wouldn't it >>> be a security issue if the OS would inform the storage device about
unused space and its location and could actually perform some kind of a
TRIM?
Am I wrong?
have to, otherwise they would randomly overwrite another file [...]
encryption is only for the data in that allocated space. The file systemThis is wrong when you have an encrypted block device, as is the case with LUKS. There, the file system sits "in" or "on top" of that block device and has no say on the en- and decryption steps.
knows nothing about that data
That means, of course, somewhat more inefficiency, but you are already paying quite a bit of that to keep privacy. The upside is that an external observer (even a malicious hard disk) don't get even to "see" which blocks have any data in them).
device, file system, etc.) apart. It's worth it.
This is, of course, different, if you have file-level encryption. This would sit "on top" of the file system (ISTR Ubuntu "sold" that for a while). But why go with plastic calipers if you can get hold of metal ones?
Cheers
my home net, is behind dd-wrt, in plain text. on an address block
that does not get thru a router. And in 30 years I have not been
touched.
On Fri, 21 Feb 2025 05:07:10 -0500
gene heskett <gheskett@shentel.net> wrote:
my home net, is behind dd-wrt, in plain text. on an address block
that does not get thru a router. And in 30 years I have not been
touched.
LUKS addresses a completely different attack vector than network
intrusion. As long as the LUKS device is decrypted on a running
machine it is not much of a help. LUKS protects data during the
encrypted state, e.g. when a stolen laptop was in shutdown state
at that time, and it helps to protect data when disks are up to
renewal and someone else has got access to the older disks later.
Without LUKS the disk erasing process needs time and might well
be quiet expensive.
On Feb 21, 2025, Frank Guthausen wrote:
On Fri, 21 Feb 2025 05:07:10 -0500
gene heskett <gheskett@shentel.net> wrote:
my home net, is behind dd-wrt, in plain text. on an address blockLUKS addresses a completely different attack vector than network
that does not get thru a router. And in 30 years I have not been
touched.
intrusion. As long as the LUKS device is decrypted on a running
machine it is not much of a help. LUKS protects data during the
encrypted state, e.g. when a stolen laptop was in shutdown state
at that time, and it helps to protect data when disks are up to
renewal and someone else has got access to the older disks later.
Without LUKS the disk erasing process needs time and might well
be quiet expensive.
Yes and no with the erasure thing -- a handful of SSD options nowadays
do onboard / integral encryption, so "erasing" the drive is essentially
just "deleting the secret key"
But then again, SSDs are quite expensive per TiB if you're talking about
a storage array
On 2/21/25 07:11, Dan Purgert wrote:
On Feb 21, 2025, Frank Guthausen wrote:
On Fri, 21 Feb 2025 05:07:10 -0500
gene heskett <gheskett@shentel.net> wrote:
my home net, is behind dd-wrt, in plain text. on an address blockLUKS addresses a completely different attack vector than network intrusion. As long as the LUKS device is decrypted on a running
that does not get thru a router. And in 30 years I have not been touched.
machine it is not much of a help. LUKS protects data during the encrypted state, e.g. when a stolen laptop was in shutdown state
at that time, and it helps to protect data when disks are up to
renewal and someone else has got access to the older disks later.
Without LUKS the disk erasing process needs time and might well
be quiet expensive.
Yes and no with the erasure thing -- a handful of SSD options nowadays
do onboard / integral encryption, so "erasing" the drive is essentially just "deleting the secret key"
But then again, SSDs are quite expensive per TiB if you're talking about
a storage array
So are spinning rust when it only lasts 2 weeks. Seacrate has sold me the
On 2/21/25 07:11, Dan Purgert wrote:[...]
On Feb 21, 2025, Frank Guthausen wrote:
On Fri, 21 Feb 2025 05:07:10 -0500
gene heskett <gheskett@shentel.net> wrote:
So are spinning rust when it only lasts 2 weeks. Seacrate has sold me the last drive they'll ever sell me. Shingled, helium filled, 2T drives, doomed when the helium escapes. They just disappeared off the end of the sata
cable. Same cable, plugged into an SSD is working perfectly over 2 years later. And working 4x faster.
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
On Feb 21, 2025, gene heskett wrote:
On 2/21/25 07:11, Dan Purgert wrote:Good thing "2 weeks" is well within a warranty period. Unless, of
On Feb 21, 2025, Frank Guthausen wrote:So are spinning rust when it only lasts 2 weeks. Seacrate has sold me the
On Fri, 21 Feb 2025 05:07:10 -0500Yes and no with the erasure thing -- a handful of SSD options nowadays
gene heskett <gheskett@shentel.net> wrote:
my home net, is behind dd-wrt, in plain text. on an address blockLUKS addresses a completely different attack vector than network
that does not get thru a router. And in 30 years I have not been
touched.
intrusion. As long as the LUKS device is decrypted on a running
machine it is not much of a help. LUKS protects data during the
encrypted state, e.g. when a stolen laptop was in shutdown state
at that time, and it helps to protect data when disks are up to
renewal and someone else has got access to the older disks later.
Without LUKS the disk erasing process needs time and might well
be quiet expensive.
do onboard / integral encryption, so "erasing" the drive is essentially
just "deleting the secret key"
But then again, SSDs are quite expensive per TiB if you're talking about >>> a storage array
course, that you opted to purchase old drives from somewhere.
On Fri, Feb 21, 2025 at 09:29:32AM -0500, gene heskett wrote:Cheers, Gene Heskett, CET.
On 2/21/25 07:11, Dan Purgert wrote:[...]
On Feb 21, 2025, Frank Guthausen wrote:
On Fri, 21 Feb 2025 05:07:10 -0500
gene heskett <gheskett@shentel.net> wrote:
So are spinning rust when it only lasts 2 weeks. Seacrate has sold me the >> last drive they'll ever sell me. Shingled, helium filled, 2T drives, doomed >> when the helium escapes. They just disappeared off the end of the sataare you sure? If I remember correctly Seagate Helium drives are all 10T and up
That was 2+ years ago, and 2T's were brand new.
cable. Same cable, plugged into an SSD is working perfectly over 2 years
later. And working 4x faster.
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
On 2/21/25 11:03, Henning Follmann wrote:
On Fri, Feb 21, 2025 at 09:29:32AM -0500, gene heskett wrote:
On 2/21/25 07:11, Dan Purgert wrote:[...]
On Feb 21, 2025, Frank Guthausen wrote:
On Fri, 21 Feb 2025 05:07:10 -0500
gene heskett <gheskett@shentel.net> wrote:
So are spinning rust when it only lasts 2 weeks. Seacrate has sold me theare you sure? If I remember correctly Seagate Helium drives are all 10T and up
last drive they'll ever sell me. Shingled, helium filled, 2T drives, doomed
when the helium escapes. They just disappeared off the end of the sata
That was 2+ years ago, and 2T's were brand new.
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
That was 2+ years ago, and 2T's were brand new.
What would I do with 2 more identical drives doomed to go away as soon as
the helium leaves?
Hi,That is a bit of a miss Andy, most would call that color red, but its
On Fri, Feb 21, 2025 at 10:11:59AM -0500, gene heskett wrote:
What would I do with 2 more identical drives doomed to go away as soon asThe magnets could augment a tin foil hat up to a whole new level of
the helium leaves?
safety; may even make the use of red SATA cables viable.
Thanks,
Andy
With a lot of emphasis on the "+" I guess, since I bought my first 2½"That was 2+ years ago, and 2T's were brand new.
2TB HDD in 2012.
StefanI was shopping in the 3.5" drives at newegg IIRC, 2T was the biggest,
.
On 2/21/25 11:42, Stefan Monnier wrote:
I was shopping in the 3.5" drives at newegg IIRC, 2T was the biggest,With a lot of emphasis on the "+" I guess, since I bought my first 2½"That was 2+ years ago, and 2T's were brand new.
2TB HDD in 2012.
        Stefan
and my 3rd woof died in 2020, and those were bought after she passed, sometime in 2021 or 2022. For $129/copy IIRC. They both just
disappeared off the end of a sata-iii cable within 36 hours of each
other with only 2 weeks spin time on them.. NOS for sure, marked as
made in 2014, so they were at least 7 damned years on somebody's shelf
when I bought the pair of them. But it took a 16mm projector lens to
read all that in the drive label. There was a time when seagate made
good hard drives. One of my cnc'd machines has a 250G in it, shut off
only for new installs, still running wheezy. No reallocated sectors,
the last time I looked, at probably 90K+ spinning hours its fine. I'd
query it, but smartctl seems to have been removed, so what now serves
that purpose of interrogating a drive on wheezy?? Thanks Stefan.
.
Cheers, Gene Heskett, CET.
On 2/21/25 11:42, Stefan Monnier wrote:
With a lot of emphasis on the "+" I guess, since I bought my first 2½"That was 2+ years ago, and 2T's were brand new.
2TB HDD in 2012.
StefanI was shopping in the 3.5" drives at newegg IIRC, 2T was the biggest, and my 3rd woof died in 2020, and those were bought after she passed, sometime in 2021 or 2022. For $129/copy IIRC. They both just disappeared off the end of a sata-iii cable within 36 hours of each other with only 2 weeks spin time
on them.. NOS for sure, marked as made in 2014, so they were at least 7 damned years on somebody's shelf when I bought the pair of them. But it took
On Feb 22, 2025, gene heskett wrote:That is possible, but they looked pristine.
On 2/21/25 11:42, Stefan Monnier wrote:I've never seen newegg sell "new" stock that's that old (in terms of manufactured date) . Sounds like you bought "used" stock off their marketplace ...
I was shopping in the 3.5" drives at newegg IIRC, 2T was the biggest, and my >> 3rd woof died in 2020, and those were bought after she passed, sometime in >> 2021 or 2022. For $129/copy IIRC. They both just disappeared off the end ofWith a lot of emphasis on the "+" I guess, since I bought my first 2½"That was 2+ years ago, and 2T's were brand new.
2TB HDD in 2012.
Stefan
a sata-iii cable within 36 hours of each other with only 2 weeks spin time >> on them.. NOS for sure, marked as made in 2014, so they were at least 7
damned years on somebody's shelf when I bought the pair of them. But it took
On Sat 22 Feb 2025 at 07:29:15 (-0500), gene heskett wrote:
[ … ]
read all that in the drive label. There was a time when seagate madeI don't think so, unless you removed it yourself:
good hard drives. One of my cnc'd machines has a 250G in it, shut off
only for new installs, still running wheezy. No reallocated sectors,
the last time I looked, at probably 90K+ spinning hours its fine. I'd
query it, but smartctl seems to have been removed, so what now serves
that purpose of interrogating a drive on wheezy??
$ ls -Glg smartmontools_5.41+svn3365-1_amd64.deb
-rw-r----- 1 578692 Jun 19 2011 smartmontools_5.41+svn3365-1_amd64.deb
$ md5sum smartmontools_5.41+svn3365-1_amd64.deb
603319007d32d580b19c065bfe34b7b7 smartmontools_5.41+svn3365-1_amd64.deb
$
was just downloaded from:
http://archive.debian.org/debian/pool/main/s/smartmontools/
[ ] smartmontools_5.41+svn3365-1+b1_kfreebsd-amd64.deb 2012-02-15 01:05 550K
[ ] smartmontools_5.41+svn3365-1+b1_kfreebsd-i386.deb 2012-02-14 22:21 550K
[ ] smartmontools_5.41+svn3365-1.debian.tar.gz 2011-06-19 15:48 38K
[TXT] smartmontools_5.41+svn3365-1.dsc 2011-06-19 15:48 1.5K
[ ] smartmontools_5.41+svn3365-1_amd64.deb 2011-06-19 16:18 565K
[ ] smartmontools_5.41+svn3365-1_armel.deb 2011-06-19 16:19 544K
[ ] smartmontools_5.41+svn3365-1_armhf.deb 2011-12-07 15:16 529K
[ ] smartmontools_5.41+svn3365-1_i386.deb 2011-06-19 15:48 567K
[ ] smartmontools_5.41+svn3365-1_ia64.deb 2011-06-19 16:19 682K
[ ] smartmontools_5.41+svn3365-1_mips.deb 2011-06-19 16:19 567K
[ ] smartmontools_5.41+svn3365-1_mipsel.deb 2011-06-20 07:34 561K
[ ] smartmontools_5.41+svn3365-1_powerpc.deb 2011-06-19 16:19 575K
[ ] smartmontools_5.41+svn3365-1_s390.deb 2011-06-19 16:19 568K
[ ] smartmontools_5.41+svn3365-1_s390x.deb 2011-12-02 00:15 576K
[ ] smartmontools_5.41+svn3365-1_sparc.deb 2011-06-19 16:19 567K
[ ] smartmontools_5.41+svn3365.orig.tar.gz 2011-06-19 15:48 631K
Take your pick.
Cheers,
David.
.
On Sun 23 Feb 2025 at 09:47:41 (-0500), gene heskett wrote:Sounds about right, but doesn't jib with POH, hence my remark about
On 2/23/25 00:00, David Wright wrote:(Aside to Gene's fan: the list lacks aarch64, aka arm64,
On Sat 22 Feb 2025 at 07:29:15 (-0500), gene heskett wrote:
[ … ]
read all that in the drive label. There was a time when seagate madehttp://archive.debian.org/debian/pool/main/s/smartmontools/
good hard drives. One of my cnc'd machines has a 250G in it, shut off
only for new installs, still running wheezy. No reallocated sectors,
the last time I looked, at probably 90K+ spinning hours its fine.
[ ] smartmontools_5.41+svn3365-1+b1_kfreebsd-amd64.deb 2012-02-15 01:05 550K
[ ] smartmontools_5.41+svn3365-1+b1_kfreebsd-i386.deb 2012-02-14 22:21 550K
[ ] smartmontools_5.41+svn3365-1.debian.tar.gz 2011-06-19 15:48 38K
[TXT] smartmontools_5.41+svn3365-1.dsc 2011-06-19 15:48 1.5K
[ ] smartmontools_5.41+svn3365-1_amd64.deb 2011-06-19 16:18 565K
[ ] smartmontools_5.41+svn3365-1_armel.deb 2011-06-19 16:19 544K
[ ] smartmontools_5.41+svn3365-1_armhf.deb 2011-12-07 15:16 529K
[ ] smartmontools_5.41+svn3365-1_i386.deb 2011-06-19 15:48 567K
[ ] smartmontools_5.41+svn3365-1_ia64.deb 2011-06-19 16:19 682K
[ ] smartmontools_5.41+svn3365-1_mips.deb 2011-06-19 16:19 567K
[ ] smartmontools_5.41+svn3365-1_mipsel.deb 2011-06-20 07:34 561K
[ ] smartmontools_5.41+svn3365-1_powerpc.deb 2011-06-19 16:19 575K
[ ] smartmontools_5.41+svn3365-1_s390.deb 2011-06-19 16:19 568K
[ ] smartmontools_5.41+svn3365-1_s390x.deb 2011-12-02 00:15 576K
[ ] smartmontools_5.41+svn3365-1_sparc.deb 2011-06-19 16:19 567K
[ ] smartmontools_5.41+svn3365.orig.tar.gz 2011-06-19 15:48 631K
because that architecture was introduced in jessie (8).)
Something seems to have removed it, but it does re-install okay butStaggering precision there! But as 114378 hours represents about
I get wildly different, and confusing readings for some things:
Power_On_hours I think has rolled over at 100000, while head
flying hours is a much much larger figure that doesn't make sense:
 5 Reallocated_Sector_Ct  0x0033  100  100  036 Pre-fail
Always      -      0
 9 Power_On_Hours          0x0032  060  011  000 Old_age
Always      -      35517
12 Power_Cycle_Count      0x0032  100  100  020   Old_age
Always      -      239
240 Head_Flying_Hours      0x0000  100  253  000   Old_age
Offline     -      114378h+51m+54.298s
13 years, that could be a realistic time, don't you think?
Mine too. Thanks David.I'd assume head flying hours wouldI've not seen posted a POH line like that before, with 060 and 011
closely match POHÂ if a 1 was added in front of POH, but that doesn't fit
not being identical numbers. But as the Threshold is 000, then
both Value and Worst can never be less than that, obviously. But
interpreting those particular values really is above my paygrade.
Cheers,
David.
.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 153:25:31 |
| Calls: | 10,383 |
| Files: | 14,054 |
| Messages: | 6,417,839 |