For using SSDs: Are there any format/mount parameters that should be set for using btrfs on SSDs (other than the "ssd" mount option)? General questions: How long is the ''delay'' for the delayed alloc? Are file allocations aligned to 4kiB boundaries, or larger? What byte value is used to pad unused space? (Aside: For some, the erased state reads all 0x00, and for others the erased state reads all 0xff.) Background: I''ve got a mix of various 120/128GB SSDs to newly set up. I will be using ext4 on the critical ones, but also wish to compare with btrfs... The mix includes some SSDs with the Sandforce controller that implements its own data compression and data deduplication. How well does btrfs fit with those compared to other non-data-compression controllers? Regards, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Martin wrote (ao):> Are there any format/mount parameters that should be set for using > btrfs on SSDs (other than the "ssd" mount option)?If possible, format the whole device, do not partition the ssd. This will guarantee proper allignment. The kernel will detect the ssd, and apply the ssd mount option automatically.> I''ve got a mix of various 120/128GB SSDs to newly set up. I will be > using ext4 on the critical ones, but also wish to compare with > btrfs...I would use btrfs on the critical ones, as btrfs has checksums to detect datacorruption.> The mix includes some SSDs with the Sandforce controller that implements > its own data compression and data deduplication. How well does btrfs fit > with those compared to other non-data-compression controllers?Since you have them both, you might want to find out yourself, and let us know ;-) FWIW (not much, as you already have them), I would not buy anything else than intel. I have about 26 of them for years now (both in servers and workstations, several series), and never had an issue. Two of my colleagues have OCZ, and both had to RMA them. Sander -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> I would not buy anything else > than intel. I have about 26 of them for years now (both in servers and > workstations, several series), and never had an issue. Two of my > colleagues have OCZ, and both had to RMA them.I guess it boils down wether you want intel also to rule the SSD market in the long term, as they do with PC processors... Comparing intel SSDs with OCZ is not that fair, as OCZ has always been low-priced bleeding edge stuff. Usually ratings at Amazon are a good indicator how reliable the product in question is. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 18, 2012 at 05:08:33PM +0200, Clemens Eisserer wrote:> > I would not buy anything else > > than intel. I have about 26 of them for years now (both in servers and > > workstations, several series), and never had an issue. Two of my > > colleagues have OCZ, and both had to RMA them. > > I guess it boils down wether you want intel also to rule the SSD > market in the long term, as they do with PC processors... > > Comparing intel SSDs with OCZ is not that fair, as OCZ has always been > low-priced bleeding edge stuff.Looking into the controllers... first there were bunch of different ones; Intel had it own design with SSD 320. Then come Sandforce; it got broadly used, despite sucking when used with FDE. Even Intel started to used Sandforce - SSD 520. How''s reliabilty of Intel differs? Latest fad is Marvell controller; again Intel joins the pack with SSD510. So, Intel is not that different anymore. -- Tomasz Torcz "God, root, what''s the difference?" xmpp: zdzichubg@chrome.pl "God is more forgiving." -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2012-05-18 at 17:32 +0200, Tomasz Torcz wrote:> On Fri, May 18, 2012 at 05:08:33PM +0200, Clemens Eisserer wrote: > > > I would not buy anything else > > > than intel. I have about 26 of them for years now (both in servers and > > > workstations, several series), and never had an issue. Two of my > > > colleagues have OCZ, and both had to RMA them. > > > > I guess it boils down wether you want intel also to rule the SSD > > market in the long term, as they do with PC processors... > > > > Comparing intel SSDs with OCZ is not that fair, as OCZ has always been > > low-priced bleeding edge stuff. > > Looking into the controllers... > first there were bunch of different ones; Intel had it own design with > SSD 320. > Then come Sandforce; it got broadly used, despite sucking when used > with FDE. Even Intel started to used Sandforce - SSD 520. How''s > reliabilty of Intel differs? > Latest fad is Marvell controller; again Intel joins the pack with SSD510. > > So, Intel is not that different anymore.The controllers themselves really aren''t that interesting any more - an SSD controller is really just an ARM or MIPS core with some flash interfaces, a SATA interface, and some ram - running proprietary firmware. Several of the Marvell devices actually have completely different firmwares (e.g. Intel''s firmware for Marvell devices was reportedly developed by them in-house), and Intel''s Sandforce firmware has some customizations for improved reliability, at the expense of some speed. -- Calvin Walton <calvin.walton@kepstin.ca> -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Freitag, 18. Mai 2012 schrieb Sander:> Martin wrote (ao): > > Are there any format/mount parameters that should be set for using > > btrfs on SSDs (other than the "ssd" mount option)? > > If possible, format the whole device, do not partition the ssd. This > will guarantee proper allignment.Current partitioning tools align at 1 MiB unless otherwise specified. And then thats only the alignment of the start of the filesystem. Not the granularity that the filesystem itself uses to align its writes. And then its not clear to me what effect proper alignment will actually have given the intelligent nature of SSD firmwares. -- Martin ''Helios'' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 19/05/12 18:36, Martin Steigerwald wrote:> Am Freitag, 18. Mai 2012 schrieb Sander: >> Martin wrote (ao): >>> Are there any format/mount parameters that should be set for using >>> btrfs on SSDs (other than the "ssd" mount option)? >> >> If possible, format the whole device, do not partition the ssd. This >> will guarantee proper allignment. > > Current partitioning tools align at 1 MiB unless otherwise specified. > > And then thats only the alignment of the start of the filesystem. > > Not the granularity that the filesystem itself uses to align its writes. > > And then its not clear to me what effect proper alignment will actually > have given the intelligent nature of SSD firmwares.That''s what I''m trying to untangle rather than just trusting to "magic". I''m also not so convinced about the "SSD firmwares" being quite so "intelligent"... So far, the only clear indications are that a number of SSDs have a performance ''sweet spot'' when you use 16kByte blocks for data transfer. Practicalities for the SSD internal structure strongly suggest that they work in chunks of data greater than 4kBytes. 4kByte operation is a strong driver for SSD manufacturers, but what compromises do they make to accommodate that? And for btrfs: Extents are aligned to "sector size" boundaries (4kBytes default). And there is a comment that setting larger sector sizes increases the CPU overhead in btrfs due to the larger memory moves needed for making inserts into the trees. If the SSD is going to do a read-modify-write on anything smaller than 16kBytes in any case, might btrfs just as well use that chunk size to good advantage in the first place? So, what is most significant? Also: btrfs has a big advantage of using checksumming and COW. However, ext4 is more mature, similarly uses extents, and also allows specifying a large "delayed allocation" time to merge multiple writes if you''re happy your system is safely on a UPS... I''m not too worried about this for MLC SSDs, but it is something that is of concern for the yet shorter modify-erase count lifespan of TLC SSDs. Regards, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html