Re: Partitioning an SSD?
On Fri, 17 Feb 2023 23:09:15 -0600 David Wright wrote: > On Thu 16 Feb 2023 at 08:59:58 (+0100), Nicolas George wrote: > > pa...@quillandmouse.com (12023-02-15): > > > Here's why you would partition a drive. Reinstalling (which I end > > > up having to do every time Debian comes out with a new version > > > > Debian is not Ubuntu, major upgrade do not break the system. > > Judging by what we read here, they do when inexperienced people > try running testing or unstable for one reason or another. > (NB I'm casting no aspertions on paulf.) > > Cheers, > David. > OMG, I've been aspersed! ;-) Actually, I probably don't need to reinstall on upgrades. I've been using Debian for 20 years or so, and I've found there are sometimes problems with upgrades. More importantly, over time I accumulate packages which I don't need and which become cruft. Reinstalling zeroes everything back to only the packages I really want, and I can guarantee that things are now "clean". Paul -- Paul M. Foster Personal Blog: http://noferblatz.com Company Site: http://quillandmouse.com Software Projects: https://gitlab.com/paulmfoster
Re: Partitioning an SSD?
On 16/02/2023 22:25, Joe wrote: Stretch installed perfectly dual-boot with Win 10 on an EFI Acer netbook, but upgrading to Buster broke booting to grub. It actually broke EFI booting completely, but I've been able to restore booting at least to Windows. And yes, I've tried everything the Net can suggest. UEFI implementation by particular vendor may be buggy. E.g. an old HP laptop may be booted up either when it is configured to load a specific .efi file or when directory structures on EFI internal hard drive partition follows layout designed for a removable storage. It ignores most of EFI variables, so e.g. it is better to remove fbx.efi fallback intended to fix boot order. When you have learned such stuff, it is easy to fix boot. Unfortunately pieces of the puzzle was spread over multiple resources. I am not surprised that installer was unable to apply proper workarounds on particular machine. I have heard that vendors may add code intended to ensure booting Windows, but other OSes may be out of luck using the same file layout.
Re: Partitioning an SSD?
On Thu 16 Feb 2023 at 08:59:58 (+0100), Nicolas George wrote: > pa...@quillandmouse.com (12023-02-15): > > Here's why you would partition a drive. Reinstalling (which I end up > > having to do every time Debian comes out with a new version > > Debian is not Ubuntu, major upgrade do not break the system. Judging by what we read here, they do when inexperienced people try running testing or unstable for one reason or another. (NB I'm casting no aspertions on paulf.) Cheers, David.
Re: Partitioning an SSD?
Cindy Sue Causey wrote: ... have you tried refind? i've been using it for several years now and while i do still have grub installed and it gets updated i primarily use refind instead. songbird
Re: Partitioning an SSD?
On Fri, 17 Feb 2023 19:33:32 + "Andrew M.A. Cater" wrote: > It's likely that LILO will go with Bookworm - I think it's more or > less unmaintained if I recall correctly, so someone needs to help you > getting this one to work. Is this your only machine? It doesn't seem to be in Bookworm now. > > As ever the Arch Wiki often also has some good tips: maybe we can > get some help from the folks who hang out here first. Cindy, you might also look at refind -- assuming the computer in question is EFI compliant. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Partitioning an SSD?
On Fri, Feb 17, 2023 at 02:11:02PM -0500, Cindy Sue Causey wrote: > > Upgrades are definitely a lot more trouble now, and yes, I do realise > > that each release is bigger and more complicated than the last. > > > Ditto. I can still remember saying (on Debian-User) that if someone > wanted to destroy an operating system, all they had to do was break > its ability to boot. A few weeks later was the last time I was able to > install a Debian release with GRUB that booted. > > LILO was the only thing that worked for me after that. Something went > wrong with mine a few months ago, and I've ended up in all kinds of > other operating systems' LiveDVDs ever since. > Cindy, What machine? What versions have you tried? Does the machine need to dual boot anything? > Even LiveDVD didn't work *for me* with Debian. There was some kind of > a showstopping library issue. Was something like libunistring. > Couldn't keep it up and running long enough to attempt a partition > install. Other systems like Mint have somehow broken the EFI/UEFI > roadblock when installed so I was taking a chance that maybe Debian > could do the same thing. > This is another one of those where the list really needs to know *exactly* what you've done so we can help troubleshoot. A machine that doesn't boot Debian stable with GRUB is in a sorry state. > A partition is currently set up with Sid (Trixie?). It broke my heart > when it didn't boot with GRUB, either. I've tried everything I can > with it with the primary assault being to attempt to duplicate all > GRUB packages that Mint uses to boot from a thumb drive. > It's likely that LILO will go with Bookworm - I think it's more or less unmaintained if I recall correctly, so someone needs to help you getting this one to work. Is this your only machine? As ever the Arch Wiki often also has some good tips: maybe we can get some help from the folks who hang out here first. With every good wish, as ever, Andy Cater > > Cindy :) > -- > Talking Rock, Pickens County, Georgia, USA > * runs with birdseed * >
Re: Partitioning an SSD?
On 2/16/23, Joe wrote: > On Thu, 16 Feb 2023 08:59:58 +0100 > Nicolas George wrote: > >> pa...@quillandmouse.com (12023-02-15): >> > Here's why you would partition a drive. Reinstalling (which I end up >> > having to do every time Debian comes out with a new version >> >> Debian is not Ubuntu, major upgrade do not break the system. >> > > That's the way it used to be, back in the days of sarge, etch, lenny... > > Stretch installed perfectly dual-boot with Win 10 on an EFI Acer > netbook, but upgrading to Buster broke booting to grub. It actually > broke EFI booting completely, but I've been able to restore booting at > least to Windows. And yes, I've tried everything the Net can suggest. > > On another machine, upgrading Buster to Bullseye broke it beyond my > ability to fix, so I installed Bullseye from scratch. > > Upgrades are definitely a lot more trouble now, and yes, I do realise > that each release is bigger and more complicated than the last. Ditto. I can still remember saying (on Debian-User) that if someone wanted to destroy an operating system, all they had to do was break its ability to boot. A few weeks later was the last time I was able to install a Debian release with GRUB that booted. LILO was the only thing that worked for me after that. Something went wrong with mine a few months ago, and I've ended up in all kinds of other operating systems' LiveDVDs ever since. Even LiveDVD didn't work *for me* with Debian. There was some kind of a showstopping library issue. Was something like libunistring. Couldn't keep it up and running long enough to attempt a partition install. Other systems like Mint have somehow broken the EFI/UEFI roadblock when installed so I was taking a chance that maybe Debian could do the same thing. A partition is currently set up with Sid (Trixie?). It broke my heart when it didn't boot with GRUB, either. I've tried everything I can with it with the primary assault being to attempt to duplicate all GRUB packages that Mint uses to boot from a thumb drive. Sid with GRUB is getting one next to the last try before the last one is LILO. An email about EFI flew by me via Linux From Scratch the other day. I'm going to go poke around over there. Maybe there are some tips there that will finally push it over the edge to success. Doing exactly that helped me a couple years ago for something unrelated so I'm laying hope on it based on prior experience. :) Cindy :) -- Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: Partitioning an SSD?
On Thu, 16 Feb 2023 08:59:58 +0100 Nicolas George wrote: > pa...@quillandmouse.com (12023-02-15): > > Here's why you would partition a drive. Reinstalling (which I end up > > having to do every time Debian comes out with a new version > > Debian is not Ubuntu, major upgrade do not break the system. > That's the way it used to be, back in the days of sarge, etch, lenny... Stretch installed perfectly dual-boot with Win 10 on an EFI Acer netbook, but upgrading to Buster broke booting to grub. It actually broke EFI booting completely, but I've been able to restore booting at least to Windows. And yes, I've tried everything the Net can suggest. On another machine, upgrading Buster to Bullseye broke it beyond my ability to fix, so I installed Bullseye from scratch. Upgrades are definitely a lot more trouble now, and yes, I do realise that each release is bigger and more complicated than the last. -- Joe
Re: Partitioning an SSD?
> Therefore, except for the narrow case of writing into a block which has > never before been written, every write on a SSD *is* an erase+write > operation. No, that would lead to terribly poor performance (both in terms of speed and in terms of wear). >> So: you read the whole block, blank it, then re-write all the other >> sectors and your updated sector? No, definitely not, that would be >> terrible. > That is exactly what I've always been told *does* happen, Don't believe everything you hear. > That's an interesting design approach. Given that I've never seen it > mentioned before, I imagine it must be comparatively recent as SSD > controller designs go. Nope. It's more like "step 1". There are rumors that some early cheap SD cards did not perform any wear-leveling, and I'm quite willing to believe them, but I'd be very surprised if those still exist. > I'm also not sure that I'd have chosen to take the trade-off of that > added complexity for the presumed added performance and lack of need to > keep track of block size handling. It's not just that: it's also cheaper. By spreading the writes around the whole flash memory, you can extend the life-expectancy of your drives very significantly, which means you can use cheaper flash cells (e.g. which may die even before reaching than 10k erase-cycle) and still have a device that will last long enough to avoid embarrassment. Yes it costs a bit more on the controller side, but this cost is mostly *design* cost, i.e. a one-time cost which has been paid already more than a decade ago. [ The other downside is the complexity of the code running on the controller, which leads to a higher risk of encountering bugs (which manifest themselves as a dead drive or at lest a total loss of your data), which is why for a while SSDs were not really more reliable than HDDs. ] > So, if this is correct, we have both less understanding and less control > of where and how data is stored on the drives than we think we do. If you want more control, you need to use flash memory cells directly, as happens sometimes in some embedded systems (those won't appear as /dev/sd devices but /dev/mtd). And then you need to use software on your CPU to do the same wear-leveling job (e.g. with UBI or jffs2 or more modern variants of that). FWIW, I liked the UBI design and it would arguably be a good idea for SSDs to expose such an API rather than to try and pretend they're "normal block devices", but that's not the way the industry chose. Stefan
Re: Partitioning an SSD?
The Wanderer (12023-02-16): > That is exactly what I've always been told *does* happen, ever since > first reading about how SSDs et cetera work, more than a decade ago. > This is the first time I've seen a suggestion to the contrary. This is surprising to me, since I have had the exact opposite information: hand-held devices with flash memory would require special, entirely-journalized filesystems like JFS2 to work properly, and that requires special MTD devices, but even the first and cheap USB sticks and CF cards would have some amount of wear-levelling. And my version is confirmed by experience: if the same whole block were written each time a sector in it is changed, then the block that contains the FAT, the superblock or the inodes for /var/log would be erased extremely frequently and die very fast, making the whole drive useless. Also, look at Google Trends or equivalent: “wear levelling” is not a new concept. > I'm also not sure that I'd have chosen to take the trade-off of that > added complexity for the presumed added performance and lack of need to > keep track of block size handling. The issue is not performance (although write performance would be impacted), and it is absolutely not the anecdotal question of aligning partition. The issue is that without wear-levelling your drive would die in less than a week of normal operation. Regards, -- Nicolas George
Re: Partitioning an SSD?
On 2023-02-16 at 08:10, Nicolas George wrote: > The Wanderer (12023-02-16): > >> filesystems et cetera aligned to physical blocks, because physical block >> size defines the minimum size that can be erased (and, therefore, >> overwritten) in any given operation, > > This is true. Note: erased, not written. My understanding is that in order to write data into a block which has already been written, the drive controller must erase the entire block and write it all again. Therefore, except for the narrow case of writing into a block which has never before been written, every write on a SSD *is* an erase+write operation. >> and therefore impacts both wear >> rates and write speeds in what is potentially a very serious way. > > This is not a logical consequence. > > You are assuming that if a block of flash memory contains B sectors, > then the block number b will contain the sectors from number B×b > included to number B×(b+1) excluded. > > 0 1 2 > ┌───┬───┬───┐ > ┌┬┬┬┬┬┬┬┬┬┬┬┐ >012346789 10 11 12 > > This is how it works for physical / logical sectors, but not for blocks > of flash memory. > > With flash memory, if you want to rewrite a sector, you can only write a > blank sector. > > So: you read the whole block, blank it, then re-write all the other > sectors and your updated sector? No, definitely not, that would be > terrible. That is exactly what I've always been told *does* happen, ever since first reading about how SSDs et cetera work, more than a decade ago. This is the first time I've seen a suggestion to the contrary. > What happens is, very schematically: the controller finds an unused > sector in a blank block (either one that has never been used or one that > has been recently erased), it writes the new data there, then updates > its remapping table to mark the old data obsolete and where the new data > is. That's an interesting design approach. Given that I've never seen it mentioned before, I imagine it must be comparatively recent as SSD controller designs go. I would not want to assume that every SSD does it; I would certainly not want to assume that there will always be such a block available, although in practice there *almost* always will be. I'm also not sure that I'd have chosen to take the trade-off of that added complexity for the presumed added performance and lack of need to keep track of block size handling. Additionally - I haven't thought it all the way through, but at a glance I'm wondering if this wouldn't also result in more total writes (thereby reducing the effective drive lifespan) than the way I've always been told it works; initial analysis isn't finding a way that it would, but I'm not sure I trust my initial analysis to have it right. > I do not know how the remapping table is kept; probably some kind of > journal with RAM caching. And of course, there are optimizations and > trade-offs: if a block contains only obsolete sectors except for a few > ones, it might make sense to move these non-obsolete sectors to a new > block to have the old one ready for erasure. I suspect constructors keep > what they do exactly as trade secrets. > > But the short of it is that it does not make sense to worry about > alignment, because even if you do, there is no guarantee that the first > sector of your partition will be the first sector of its block, and even > if it is it might not be tomorrow after it has been rewritten by the OS, > i.e. reallocated by the controller. So, if this is correct, we have both less understanding and less control of where and how data is stored on the drives than we think we do. Even if/though it's not common to *need* such, that hardly seems like it can possibly be considered a good thing. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Partitioning an SSD?
The Wanderer (12023-02-16): > filesystems et cetera aligned to physical blocks, because physical block > size defines the minimum size that can be erased (and, therefore, > overwritten) in any given operation, This is true. Note: erased, not written. > and therefore impacts both wear > rates and write speeds in what is potentially a very serious way. This is not a logical consequence. You are assuming that if a block of flash memory contains B sectors, then the block number b will contain the sectors from number B×b included to number B×(b+1) excluded. 0 1 2 ┌───┬───┬───┐ ┌┬┬┬┬┬┬┬┬┬┬┬┐ 012346789 10 11 12 This is how it works for physical / logical sectors, but not for blocks of flash memory. With flash memory, if you want to rewrite a sector, you can only write a blank sector. So: you read the whole block, blank it, then re-write all the other sectors and your updated sector? No, definitely not, that would be terrible. What happens is, very schematically: the controller finds an unused sector in a blank block (either one that has never been used or one that has been recently erased), it writes the new data there, then updates its remapping table to mark the old data obsolete and where the new data is. I do not know how the remapping table is kept; probably some kind of journal with RAM caching. And of course, there are optimizations and trade-offs: if a block contains only obsolete sectors except for a few ones, it might make sense to move these non-obsolete sectors to a new block to have the old one ready for erasure. I suspect constructors keep what they do exactly as trade secrets. But the short of it is that it does not make sense to worry about alignment, because even if you do, there is no guarantee that the first sector of your partition will be the first sector of its block, and even if it is it might not be tomorrow after it has been rewritten by the OS, i.e. reallocated by the controller. Regards, -- Nicolas George
Re: Partitioning an SSD?
On Thu, Feb 16, 2023 at 02:22:56AM -0500, Felix Miata wrote: What physical boundaries do SSDs have to report? All I know about that are exposed are sector size and sector count. I have yet to find one where logical/physical were not 512B/512B. Don't worry about it; modern partition tools align on 1MB, which works for basically anything.
Re: Partitioning an SSD?
Am 16.02.2023 um 13:30 schrieb DdB: > Unfortunately, the > data set related to this, i could gather personally is not large > enough to be telling. https://www.servethehome.com/ssd-alignment-quickly-benchmark-ssd/
Re: Partitioning an SSD?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 16.02.2023 um 13:00 schrieb The Wanderer: > This being the very first time I can remember having encountered > even the suggestion that there's no need to be concerned about > erase-block sizes when dealing with SSDs et cetera, I hope it's > understandable that I'd want to get things clarified. I second that. To me, it sounds like 2 different mind sets (a.k.a. belief systems) suggesting different behaviors. Unfortunately, the data set related to this, i could gather personally is not large enough to be telling. And my belief was - just as yours - supported by my inner pictures of what i think is going on inside the SSD. I did not conduct performance tests with and without alignment myself. But i recall reading about them, from users/admins of large zfs sites (on zfs.discuss mailing list) and also from a hardware store (was it backblaze, or something?), and later never questionned my belief. But who am i to speak about this? - I just gave my honest best opinion, that has been guiding my own efforts since years. But i dont care, if some people prefer disregarding such advice. Everyone does, what he thinks is best for them. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEumgd33HMGU/Wk4ZRe3aiXLdoWD0FAmPuIdQACgkQe3aiXLdo WD3X0Q/+MoTuqcbwovYXBiw4CanXDMiSAy71krXPrMHdADBWHP4Rl7rPHSGs3mRf r2WM0AdmUBDVbK+EsSqbw33BdW3HMDy0tZ7z9GTwOff9wD7RJbsoSMwtxI8yrgaX g/7N4YqsocKAzainWPXqFJTbZzTI3M2PjBoyuqBJ1JF+LSuLzUi6DK5Z0uySG6HD KMiGswVzqYpOtR8XYPl9Q7x4/3Zt3buCRRtaISkW+0MwrjRbDJdy/h7hKV7l27C7 6f1clZ8Glqv43/ZCCympORdrJT4ddxGNipd8/gEAC/DlgDfdt9wSTOy7eiQcnGIZ e4HrvteSqVX731ojjcF9pt1ujIqDzW28FxT1KnUozc/sc4JbrrbHzaDzH1PdqWEi TcXGcDxVzY2iQ9Q5/217F2UDWLE+5mWAgOhvmYHxCv5tImSfTaKPYKec5NvlhfOo UaYHEEGAVFpThGPlJXF/NbFQFo+Oyp/E6bYMSGTl2/nIU7K2s5QidF5EG9IY3Tcj DnMigUSWgpnWAbd8Z4muluCuEkPqJcYYTx/2YS13u2VgNPm8gbUS6CM+CIu607qv Rkl7wCa86hxegoslk+2klGDm3CGBku89ii5M6iIwPLTZjAPY3W7e6Olz3f9avogW l6gWv+wIHGLwE1o3ncq5Au5EJA037CnU3fnlbzUPOxmCq2qqA3E= =ELkf -END PGP SIGNATURE-
Re: Partitioning an SSD?
On 2023-02-16 at 05:45, Nicolas George wrote: > DdB (12023-02-16): > >> Am 16.02.2023 um 09:31 schrieb Felix Miata: >> > None of the 25 or so SSDs/NVMEs I have have 4k sectors. e.g. >> >> Wow, they must be rather old, then. ;-) >> >> I know, i am not the only one ... >> https://serverfault.com/questions/1113068/how-to-find-page-size-of-my-ssd > > Of course you are not the only one. But the real answer was to be found > in another random stackoverflow forum: > > When you have 512 octets logical sectors and 4096 octets physical > sectors, you really have eight logical sectors in a physical one, it > matters to align the small ones inside the big ones. > > But with blocks of flash memory, there is not constant nor regular > mapping of sectors to blocks, so the information about the block size is > not useful outside of the disk controller. I'm already confused by the way terminology is being used in this conversation (and I wouldn't be surprised I wasn't the only one), but this is just "huh?" to me. My understanding is that with SSDs it's even *more* important to keep filesystems et cetera aligned to physical blocks, because physical block size defines the minimum size that can be erased (and, therefore, overwritten) in any given operation, and therefore impacts both wear rates and write speeds in what is potentially a very serious way. The way I interpret what I read you as having written, here, is that on the contrary block sizes can be completely disregarded because the disk controller will handle all of that alignment stuff internally. This being the very first time I can remember having encountered even the suggestion that there's no need to be concerned about erase-block sizes when dealing with SSDs et cetera, I hope it's understandable that I'd want to get things clarified. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Partitioning an SSD?
DdB (12023-02-16): > Am 16.02.2023 um 09:31 schrieb Felix Miata: > > None of the 25 or so SSDs/NVMEs I have have 4k sectors. e.g. > > Wow, they must be rather old, then. ;-) > > I know, i am not the only one ... > https://serverfault.com/questions/1113068/how-to-find-page-size-of-my-ssd Of course you are not the only one. But the real answer was to be found in another random stackoverflow forum: When you have 512 octets logical sectors and 4096 octets physical sectors, you really have eight logical sectors in a physical one, it matters to align the small ones inside the big ones. But with blocks of flash memory, there is not constant nor regular mapping of sectors to blocks, so the information about the block size is not useful outside of the disk controller. Regards, -- Nicolas George
Re: Partitioning an SSD?
Am 16.02.2023 um 09:31 schrieb Felix Miata: > None of the 25 or so SSDs/NVMEs I have have 4k sectors. e.g. Wow, they must be rather old, then. ;-) I know, i am not the only one ... https://serverfault.com/questions/1113068/how-to-find-page-size-of-my-ssd
Re: Partitioning an SSD?
DdB composed on 2023-02-16 09:15 (UTC+0100): > Felix Miata wrote: >> What physical boundaries do SSDs have to report? All I know about that are >> exposed >> are sector size and sector count. I have yet to find one where >> logical/physical >> were not 512B/512B. > That is what i meant: nowadays SSD's at least are AF Advanced Format = > 4KB sector size), but even much more than that. Do not trust the values > reported but check documentation properly. 512B is only virtual > (sometimes called 512e - for emulated). You have it backwards. All HDDs tooled since 2011 are advanced format with 4k physical sectors. e.g. # parted /dev/sdb print | head Model: ATA ST1000DM003-1CH1 (scsi) Disk /dev/sdb: 1000GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End SizeFile system Name Flags 1 1049kB 420MB 419MBST1jh6e reserved 2 420MB 756MB 336MBST1jh6e realboot backup template 3 756MB 1092MB 336MBST1jh6e realboot None of the 25 or so SSDs/NVMEs I have have 4k sectors. e.g. # parted -l | head Model: ATA TEAM T253X2256G (scsi) Disk /dev/sda: 256GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End SizeFile system Name Flags 1 1049kB 337MB 336MB fat32 TG1P01 EFI System (ESP) T253X 2295 boot, esp 2 337MB 1885MB 1549MB linux-swap(v1) TG1P02 Linux Swap swap 3 1885MB 2305MB 419MB ext2TG1P03 Linux reservation -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: Partitioning an SSD?
Am 16.02.2023 um 08:22 schrieb Felix Miata: > What physical boundaries do SSDs have to report? All I know about that are > exposed > are sector size and sector count. I have yet to find one where > logical/physical > were not 512B/512B. That is what i meant: nowadays SSD's at least are AF Advanced Format = 4KB sector size), but even much more than that. Do not trust the values reported but check documentation properly. 512B is only virtual (sometimes called 512e - for emulated).
Re: Partitioning an SSD?
pa...@quillandmouse.com (12023-02-15): > Here's why you would partition a drive. Reinstalling (which I end up > having to do every time Debian comes out with a new version Debian is not Ubuntu, major upgrade do not break the system. -- Nicolas George
Re: Partitioning an SSD?
DdB composed on 2023-02-16 07:44 (UTC+0100): > I do use (NVMe-) SSD, and i did partition it. > I did it to make sure, pages/partitions start on PHYSICAL boundaries, > not the logical ones reported to satisfy Windooze. What physical boundaries do SSDs have to report? All I know about that are exposed are sector size and sector count. I have yet to find one where logical/physical were not 512B/512B. FWIW, I too keep /homes on a separate filesystems from /s. It's sensible segregation. An OS is easily changed without disturbing user data. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: Partitioning an SSD?
Am 16.02.2023 um 07:44 schrieb DdB: > I do use (NVMe-) SSD, and i did partition it. > I did it to make sure, pages/partitions start on PHYSICAL boundaries, > not the logical ones reported to satisfy Windooze. Not every model > reports correct hardware parameters to the OS. > > What i would recommend, is to use GPT/UEFI if possible, to avoid future > hassle and limitations (gdisk being your friend) and set alignment > manually to the physical page size. That is going to avoid eventual > read/write cycles to accomodate emulating 512e virtual sectors and also > wasting space on the drive. > > Apart from that, i do not think, you would be limited to do anything you > want with the installation. My personal preference has always been to > have room for 3 OS partitions (20GB max each), one for real, one for > fast cloning/backup and one for wild experimentation. Any serious backup > belonging onto outside media/computer anyway. > > just my 2 cents > > But everybody has different needs and habits, so do, whatever suits you. > > I forgot to mention, that i prefer using real RAM to swapping, especially on SSD's, as those fast use patitions (swap space and the like) eat those up literally and wear them out quickly. Enough RAM makes any system fast, so for me swap space doesnt make sense.
Re: Partitioning an SSD?
Am 15.02.2023 um 23:58 schrieb PMA: > Dear Debian, > > I'm preparing to install Debian 11.5.0 on a new computer. > Its drives are SSDs, not the HDDs I've been accustomed > to and have always fastidiously *partitioned*. > > With my file groupings already well differentiated c/o > directory-tree layout, is there any further advantage > to be had in partitioning *these* drives? > > (I do understand somewhat the difference between the > drive types -- e.g., that SSDs don't assign functional > space. I'm just not sure what other issue may apply.) > > Thanks in advance for your time! > > Best regards, > Peter Armstrong > > I do use (NVMe-) SSD, and i did partition it. I did it to make sure, pages/partitions start on PHYSICAL boundaries, not the logical ones reported to satisfy Windooze. Not every model reports correct hardware parameters to the OS. What i would recommend, is to use GPT/UEFI if possible, to avoid future hassle and limitations (gdisk being your friend) and set alignment manually to the physical page size. That is going to avoid eventual read/write cycles to accomodate emulating 512e virtual sectors and also wasting space on the drive. Apart from that, i do not think, you would be limited to do anything you want with the installation. My personal preference has always been to have room for 3 OS partitions (20GB max each), one for real, one for fast cloning/backup and one for wild experimentation. Any serious backup belonging onto outside media/computer anyway. just my 2 cents But everybody has different needs and habits, so do, whatever suits you.
Re: Partitioning an SSD?
On Wed, Feb 15, 2023 at 11:23:52PM -0500, pa...@quillandmouse.com wrote: Here's why you would partition a drive. Reinstalling (which I end up having to do every time Debian comes out with a new version) means overwriting the storage. I already acknowleged that people can do what they want based on personal preference. I don't think I've ever personally reinstalled because of an upgrade; the machine I'm writing this on was first installed more than a decade ago. FWIW, I've also got stuff in many directories other than /home that I care about, so backups are more important to me than only having /home.
Re: Partitioning an SSD?
On Wed, 15 Feb 2023 18:45:49 -0500 Michael Stone wrote: > > I don't personally think there's a point in partitioning any storage > device on a user system these days beyond what's required to boot. If > you want to do more, that's a personal preference. Being an SSD > doesn't really change things. > Here's why you would partition a drive. Reinstalling (which I end up having to do every time Debian comes out with a new version) means overwriting the storage. If your home partition is part of that, it's gone too, along with your music, photos and valuable documents. Likewise if something catastrophic happens to the drive itself. You could store everything together. Then you could back up the home directory and then copy it back, I suppose. I just find it simpler to have a separate partition for home. For what it's worth to the original poster, my root and home partitions are on their own partitions on separate SSDs. SSDs versus HDDs isn't really an important distinction when it comes to partitioning. Paul -- Paul M. Foster Personal Blog: http://noferblatz.com Company Site: http://quillandmouse.com Software Projects: https://gitlab.com/paulmfoster
Re: Partitioning an SSD?
On 2/15/23 14:58, PMA wrote: Dear Debian, I'm preparing to install Debian 11.5.0 on a new computer. Please tell us about the computer, the environment it will be deployed in (including Internet access or none), and the role of the computer. Its drives are SSDs, not the HDDs I've been accustomed to and have always fastidiously *partitioned*. With my file groupings already well differentiated c/o directory-tree layout, is there any further advantage to be had in partitioning *these* drives? (I do understand somewhat the difference between the drive types -- e.g., that SSDs don't assign functional space. I'm just not sure what other issue may apply.) Thanks in advance for your time! Best regards, Peter Armstrong David
Re: Partitioning an SSD?
On 15/02/2023 22:58, PMA wrote: is there any further advantage to be had in partitioning *these* drives? Although some people still prefer to leave about 20% of a SSD as raw unpartitioned space, so SSD can spare/level out sectors to that empty space, this is IMO on longer necessary, as you can report entire free space as void of data to the SSD, and it will TRIM it on demand. You can do it by manually invoking fstrim, or using systemd timer, or using async discard if you using Btrfs. TL;DR: Use ENTIRE space however you want. After complete install just make sure that both services fstrim and fstrim.timer are enabled and running, that's all. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: Partitioning an SSD?
On 16/2/23 07:45, Michael Stone wrote: I don't personally think there's a point in partitioning any storage device on a user system these days beyond what's required to boot. If you want to do more, that's a personal preference. Being an SSD doesn't really change things. I agree with that wholeheartedly. But I will add Logical Volumes are to be avoided for most user systems. They add complexity and problems in management that far outway any benfit they give to a user system - usually none. Jeremy
Re: Partitioning an SSD?
On Wed, Feb 15, 2023 at 05:58:47PM -0500, PMA wrote: I'm preparing to install Debian 11.5.0 on a new computer. Its drives are SSDs, not the HDDs I've been accustomed to and have always fastidiously *partitioned*. With my file groupings already well differentiated c/o directory-tree layout, is there any further advantage to be had in partitioning *these* drives? (I do understand somewhat the difference between the drive types -- e.g., that SSDs don't assign functional space. I'm just not sure what other issue may apply.) I don't personally think there's a point in partitioning any storage device on a user system these days beyond what's required to boot. If you want to do more, that's a personal preference. Being an SSD doesn't really change things.
