freebsd-swap on ssd
Julian Elischer
julian at freebsd.org
Fri Feb 17 19:41:55 UTC 2012
> On Fri Feb 17 12, Julian Elischer wrote:
>> On 2/17/12 11:09 AM, Alexander Best wrote:
>>> On Fri Feb 17 12, Julian Elischer wrote:
>>>> On 2/17/12 6:16 AM, Alexander Best wrote:
>>>>> hi there,
>>>>>
>>>>> putting a freebsd-ufs partition on an ssd isn't recommended, since the
>>>>> ufs
>>>>> structure (unlike zfs e.g.) requires certain data to be continuously
>>>>> written to
>>>>> a fixed location and thus will cause the ssd to quickly run out of
>>>>> write-cycles
>>>>> and die.
>>>> nonsense.
>>>> the SSD doesn't use the same flash for the same logical locatio each time!
>>>> it maps it to different locations each time.
>>> i simply repeated what kirk mckusick said in the SU+J introduction video.
>>> he
>>> said for exactly this reason ufs should not be used on an ssd, since stuff
>>> like
>>> inode entries live in a fixed location, whereas with zfs the ueberblock can
>>> live in 128 locations. also in case of SU+J, where the journal only takes
>>> up a
>>> very small part of the disk due to the fact that it's only tracking
>>> metadata
>>> changes and isn't doing logging (like gjournal), there's also the chance
>>> to run
>>> out of write-cycles.
>> I think he meant ON A RAW FLASH DEVICE
>> SSD's have all that taken care of transparently.
> ahh is see. i wasn't aware of that. so in theory doing
>
> while true; do dd if=/dev/zero bs=4096 of=/dev/ssd count=1; done
>
> will not overwrite the first sector continuously, but the ssd controller will
> make sure the writes are being sprinkled all over the actual ssd?
yes. that's the differnce between an SSD and a lump of flash soldered
onto a motherboard
> cheers.
> alex
>
>> There are special file systems for raw flash devices that take all
>> that into account,
>> and ffs is not one of them.
>>
More information about the freebsd-fs
mailing list