I can't remeber if I wished you guys a happy xmas or not. well here's a
bleated one.

got to laugh at the discussions about ssds and hds, i don't know enough
to add to it, though i don't know that anyone here really knows what
they're talking about there either.

I'm still working on my ahci driver, it still crashes occasionaly in
qemu, well consitantly if i do certain things.

All this talk about sector size, got me wondering if NVMe has
configurable sector size, because AHCI and ATA both use 512 bytes
regardless of the sector size of the underlying disk. got me wondering if
i read more consecutive sectors, perhaps it would be quicker.

(note, ata has configurable sector size i believe, but it's always 512
bytes)

So, how would a filesystem get around that? Enquiring minds want to know.
I'm using minix 3 filesystem which has a 1024 block size, but i still
have to read 2 sectors for every block.

Anyway, I've had too much beer. Lets say, I'm with Paul on the wariness
of lifespans of ssds, on the other hand I DO have a 1 TB NVMe SSD as my
main drive, and it hasn't failed yet, touch wood.

Andrew

--
|03Andrew Pamment |08(|11apam|08)
|13Happy|10Land |14v2.0|08!|07


--- Talisman v0.35-dev (Windows/x64)
* Origin: The Grinning Cat - telnet://gcat.talismanbbs.com:11823 (21:1/151)

Re: Happy Holidays
By: apam to All on Mon Dec 27 2021 06:11 pm

So, how would a filesystem get around that? Enquiring minds want to know. I'm using minix 3 filesystem which has a 1024 block size, but i still
have to read 2 sectors for every block.

SSDs have better survivability in theory, because they don't have moving
parts. On the other
hand, I don't think write wear does an SSD in as fast as a lot of people fears unless they are doing something very wrong with the drive.

That said, I have discarded more hard drives from bad blocks than from massive failures (if you get one or two unrecoverable write errors in a drive, it may mean the drive ran out of spare backup block for remapping defective sectors, which means then drive is effectively dying). A lot of SSD proponents claim SSDs are supperior because they don't have mobile parts that will break, but I don't think mobile parts breaking is such a big cause of death these days unless you are abusing the drive (for example, using aggressive power management).

--
gopher://gopher.richardfalken.com/1/richardfalken
--- SBBSecho 3.14-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (21:2/138)

I can't remeber if I wished you guys a happy xmas or not. well here's a bleated one.

hapy bleated xmas 2 u too!

I'm still working on my ahci driver, it still crashes occasionaly in
qemu, well consitantly if i do certain things.

All this talk about sector size, got me wondering if NVMe has
configurable sector size, because AHCI and ATA both use 512 bytes regardless of the sector size of the underlying disk. got me wondering if

I have never tried to create a low level driver. I wouldn't even know where to start, to be honest. I don't do assembly. So, maybe you know more than I do.

One thing I do know, is this: ALL modern formats (NTFS, OSX, EXT) use 4kb
block size.

So, how would a filesystem get around that? Enquiring minds want to know. I'm using minix 3 filesystem which has a 1024 block size, but i still
have to read 2 sectors for every block.

Sorry, I definitely don't understand. Are you trying to use a 1kb filesystem on modern storage? If that's the case, you will possibly waste another 3kb with every read/write action, solid state or platter. I am certain that 4kb is the minimum for any current storage device.

Anyway, I've had too much beer. Lets say, I'm with Paul on the wariness
of lifespans of ssds, on the other hand I DO have a 1 TB NVMe SSD as my main drive, and it hasn't failed yet, touch wood.

*touches forehead*

Maybe we both have had too much beer. I know I have! But, it's my birthday,
so I'm allowed!

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (21:4/135)

That said, I have discarded more hard drives from bad blocks than from massive failures (if you get one or two unrecoverable write errors in a drive, it may mean the drive ran out of spare backup block for remapping defective sectors, which means then drive is effectively dying). A lot
of SSD proponents claim SSDs are supperior because they don't have
mobile parts that will break, but I don't think mobile parts breaking is such a big cause of death these days unless you are abusing the drive
(for example, using aggressive power management).

If a HDD runs out of spare sectors, throw it out! (or sell it to
*average joe* t(-_-t) )

A SPINNING PLATTER IS THE SAME AS A BICYCLE WHEEL! If you move it, it will react...usually by scraping against the read/write head.

Of course...there is no platter, nor head, in a solid state drive...

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (21:4/135)

Re: Re: Happy Holidays
By: McDoob to Arelor on Mon Dec 27 2021 06:46 am

A SPINNING PLATTER IS THE SAME AS A BICYCLE WHEEL! If you move it, it will react...usually by scraping against the read/write head.

Modern drives have acceleration sensors that park the drive's head when a sudden acceleration (such as a drop) is detected. This is the reason why many reckless users get away with using laptops in bus trips without getting the whole thing explode in their faces. I have had home servers under load fall over because somebody toppled them and show no damage after throughful testing.

The head parking mechanism may be damaged after intensive use, which is the reason why aggressive power saving in hard drives may end up killing them. When then ive parks its head when going into power saving, then wakes up and moves the head to the platter, then goes instandby again, many times per hour... that is bad.

--
gopher://gopher.richardfalken.com/1/richardfalken
--- SBBSecho 3.14-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (21:2/138)

I have never tried to create a low level driver. I wouldn't even know
where to
start, to be honest. I don't do assembly. So, maybe you know more than
I do.

I don't know, my drivers are in C not ASM, though there are parts of my
kernel in ASM (but I don't really get on with ASM that well).

I wasn't suggesting I know more or less than anyone really, because I
don't know. I was just a little drunk and found the conversation amusing.
:)

Sorry, I definitely don't understand. Are you trying to use a 1kb
filesystem on
modern storage? If that's the case, you will possibly waste another
3kb with
every read/write action, solid state or platter. I am certain that 4kb
is the

No. What I am saying is regardless of the block size of the filesystem,
and regardless of the blocksize of the disk, accessing the disk via AHCI
or ATA, you end up using 512 byte sectors.

Block size of filesystems is more relevant to being able to address
larger storage spaces than it has to do with accessing the underlying
storage.

So, ext4 or ntfs or whatever which may have a 4k blocksize (I think that
it's actually configureable when you create the filesystem) it will need
to read 8 sectors for every block it reads.

Having a smaller blocksize on a filesystem will allow you to have smaller files, ie not multiples of 4kb, but it also means you can't address as
much storage space.

Now, I THINK, modern drives have a cache, so if you read 8 consecutive
sectors (as you would with a 4kb filesystem) then that would I assume
reduce the wear of the drive.

Maybe we both have had too much beer. I know I have! But, it's my
birthday,
so I'm allowed!

Happy birthday! And I am not sure, is "too much beer" a thing? ;P

Andrew

--
|03Andrew Pamment |08(|11apam|08)
|13Happy|10Land |14v2.0|08!|07


--- Talisman v0.35-dev (Windows/x64)
* Origin: The Grinning Cat - telnet://gcat.talismanbbs.com:11823 (21:1/151)

Happy birthday! And I am not sure, is "too much beer" a thing? ;P

Yes. But you don't find out until the next day. ;)

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (21:4/135)