hi all, I would like to know what are the ssd specific optimisations in btrfs . I read from the archives that "mount -o ssd option, which clusters file data writes together regardless of the directory the files belong to. There are a number of other performance tweaks for SSD, aimed at clustering metadata and data writes to better take advantage of the hardware" Also I read that there are some allocator changes specific to ssd. I would like to know what these changes are. I tried to see the v 0.17 code to understand what ssd specific changes are. I saw that the SSD option was used in two places in function find_free_extent and in function btrfs_defrag_leaves. I couldn''t gather much information from the code. So can somebody help me understand the optimisations and changes in btrfs. are any documentation or reading material available? Thanks in advance for helping, Mugunthan -- 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, Feb 20, 2009 at 04:56:55PM +0530, srimugunthan dhandapani wrote:> hi all, > I would like to know what are the ssd specific optimisations in btrfs . > I read from the archives that > > "mount -o ssd option, which clusters file data writes together regardless of > the directory the files belong to. There are a number of other performance > tweaks for SSD, aimed at clustering metadata and data writes to better take > advantage of the hardware" > Also I read that there are some allocator changes specific to ssd. I > would like to know what these changes are. > > I tried to see the v 0.17 code to understand what ssd specific changes are. > I saw that the SSD option was used in two places in function > find_free_extent and in function btrfs_defrag_leaves. > I couldn''t gather much information from the code. > So can somebody help me understand the optimisations and changes in btrfs. > are any documentation or reading material available? > Thanks in advance for helping,So really the only thing that changes with SSD is that we keep track of the last place we allocated for data, and start looking from there again. Since there is no seek penalty we can just be dumb in the allocator and use up space sequentially regardless of the file instead of trying to group allocations for the file/dir. Thanks, Josef -- 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, 2009-02-20 at 11:01 -0500, Josef Bacik wrote:> On Fri, Feb 20, 2009 at 04:56:55PM +0530, srimugunthan dhandapani wrote: > > hi all, > > I would like to know what are the ssd specific optimisations in btrfs . > > I read from the archives that > > > > "mount -o ssd option, which clusters file data writes together regardless of > > the directory the files belong to. There are a number of other performance > > tweaks for SSD, aimed at clustering metadata and data writes to better take > > advantage of the hardware" > > Also I read that there are some allocator changes specific to ssd. I > > would like to know what these changes are. > > > > I tried to see the v 0.17 code to understand what ssd specific changes are. > > I saw that the SSD option was used in two places in function > > find_free_extent and in function btrfs_defrag_leaves. > > I couldn''t gather much information from the code. > > So can somebody help me understand the optimisations and changes in btrfs. > > are any documentation or reading material available? > > Thanks in advance for helping, > > So really the only thing that changes with SSD is that we keep track of the last > place we allocated for data, and start looking from there again. Since there is > no seek penalty we can just be dumb in the allocator and use up space > sequentially regardless of the file instead of trying to group allocations for > the file/dir. Thanks,We already do this with metadata, but the ssd mode makes the metadata cluster that we try to allocate larger now. This change was made based on benchmarks with an SSD that is bad at random writes, and it made a significant difference for metadata writes. The short answer is that in ssd mode we don''t try to avoid random reads. -chris -- 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 Sat, Feb 21, 2009 at 3:30 AM, Chris Mason <chris.mason@oracle.com> wrote:> The short answer is that in ssd mode we don''t try to avoid random reads.In the ideal future where SSDs can be run without a flimsy hardware FTL, and btrfs can use something like ubi directly, would SSD mode also be able to enable more intelligent wear levelling and safer use of eraseblocks? I''ve read that one of the potentially crippling limitations of ZFS is that even its reliability features depend largely on being able to perform atomic writes, which are currently impossible (?) on flash media where a block has to be erased before it can be updated, clearly not an atomic operation. Is there any solution to this that doesn''t depend on a battery backup? Clearly it''s not something a filesystem can practically solve. -- Dmitri Nikulin Centre for Synchrotron Science Monash University Victoria 3800, Australia -- 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
Dmitri Nikulin wrote:> On Sat, Feb 21, 2009 at 3:30 AM, Chris Mason <chris.mason@oracle.com> wrote: > >> The short answer is that in ssd mode we don''t try to avoid random reads. >> > > In the ideal future where SSDs can be run without a flimsy hardware > FTL, and btrfs can use something like ubi directly, would SSD mode > also be able to enable more intelligent wear levelling and safer use > of eraseblocks? > > I''ve read that one of the potentially crippling limitations of ZFS is > that even its reliability features depend largely on being able to > perform atomic writes, which are currently impossible (?) on flash > media where a block has to be erased before it can be updated, clearly > not an atomic operation. Is there any solution to this that doesn''t > depend on a battery backup? Clearly it''s not something a filesystem > can practically solve. > >Well this is not really a problem with enterprise class SSD drives. They almost all use super capacitors to be able to have enough power to flush the dram cache to the nand chips without the need for any external battery backup. Steve> -- > Dmitri Nikulin > > Centre for Synchrotron Science > Monash University > Victoria 3800, Australia > -- > 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 >-- 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 Mon, Feb 23, 2009 at 4:44 AM, Steven Pratt <slpratt@austin.ibm.com> wrote:> Well this is not really a problem with enterprise class SSD drives. They > almost all use super capacitors to be able to have enough power to flush the > dram cache to the nand chips without the need for any external battery > backup.That''s excellent, but until consumer-level drives have the same feature, the fact remains that consumer SSDs are a net loss in reliability compared to consumer rotating disks, where by their marketing material they should be a gain. That''s an issue with SSDs in general and certainly no fault of btrfs, I''m just curious if there''s anything that can be done in a filesystem to minimise the damage of a lost eraseblock. In fact, will metadata mirroring solve this for us already, or does that still not handle failures in some "critical" blocks at the root of a filesystem? -- Dmitri Nikulin Centre for Synchrotron Science Monash University Victoria 3800, Australia -- 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 Mon, Feb 23, 2009 at 10:06 AM, Dmitri Nikulin <dnikulin@gmail.com> wrote:> On Mon, Feb 23, 2009 at 4:44 AM, Steven Pratt <slpratt@austin.ibm.com> wrote: >> Well this is not really a problem with enterprise class SSD drives. They >> almost all use super capacitors to be able to have enough power to flush the >> dram cache to the nand chips without the need for any external battery >> backup. > > That''s excellent, but until consumer-level drives have the same > feature, the fact remains that consumer SSDs are a net loss in > reliability compared to consumer rotating disks, where by their > marketing material they should be a gain. That''s an issue with SSDs in > general and certainly no fault of btrfs, I''m just curious if there''s > anything that can be done in a filesystem to minimise the damage of a > lost eraseblock. In fact, will metadata mirroring solve this for us > already, or does that still not handle failures in some "critical" > blocks at the root of a filesystem? >A well-designed SSD should survive power cycling and should provide atomicity of flush operation regardless of the underlying flash operations. I don''t expect that users of SSD have different requirements about atomicity. The existence of super capacitors may help increasing the performance as well as the reliability of data. However, that should not be the necessary condition for the atomicity. -- Dongjun -- 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 Mon, Feb 23, 2009 at 12:22 PM, Dongjun Shin <djshin90@gmail.com> wrote:> A well-designed SSD should survive power cycling and should provide atomicity > of flush operation regardless of the underlying flash operations. I don''t expect > that users of SSD have different requirements about atomicity.Well that''s my point, it "should" provide atomicity, but is this the case for consumer SSDs? It is certainly NOT the case for cheap USB-based flash media and AFAIK not for CF either. -- Dmitri Nikulin Centre for Synchrotron Science Monash University Victoria 3800, Australia -- 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 Mon, Feb 23, 2009 at 11:33 AM, Dmitri Nikulin <dnikulin@gmail.com> wrote:> On Mon, Feb 23, 2009 at 12:22 PM, Dongjun Shin <djshin90@gmail.com> wrote: >> A well-designed SSD should survive power cycling and should provide atomicity >> of flush operation regardless of the underlying flash operations. I don''t expect >> that users of SSD have different requirements about atomicity. > > Well that''s my point, it "should" provide atomicity, but is this the > case for consumer SSDs? It is certainly NOT the case for cheap > USB-based flash media and AFAIK not for CF either. >AFAIK, all enterprise and consumer SSDs have atomicity requirements because they''re designed to replace the HDD without changes to the OS. USB or any kind of flash-based cards have different requirements. They''re optimized for cost and the priority for the atomicity is low. Moreover, they can be plugged out without prior notice to OS. -- Dongjun -- 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 Mon, Feb 23, 2009 at 12:22 PM, Dongjun Shin <djshin90@gmail.com> wrote:> A well-designed SSD should survive power cycling and should provide atomicity > of flush operation regardless of the underlying flash operations. I don''t expect > that users of SSD have different requirements about atomicity.A reliable system should be based on the assumption that the underlying parts are unreliable. Therefore, we should do as much as possible to make sure the reliability in our filesystem instead of leaning on the SSDs. -- Seth Huang -- 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 -- 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 Mon, Feb 23, 2009 at 2:17 PM, Seth Huang <seth.hg@gmail.com> wrote:> On Mon, Feb 23, 2009 at 12:22 PM, Dongjun Shin <djshin90@gmail.com> wrote: >> A well-designed SSD should survive power cycling and should provide atomicity >> of flush operation regardless of the underlying flash operations. I don''t expect >> that users of SSD have different requirements about atomicity. > > A reliable system should be based on the assumption that the underlying parts are unreliable. Therefore, we should do as much as possible to make sure the reliability in our filesystem instead of leaning on the SSDs.I generally agree with this approach, however, it would clearly have a performance penalty. If possible it should be optional so that, on a reliable media, the hardware can do the hard work and software can perform well. But it might be too much to ask that btrfs support mkfs/mount options for every distinct class of storage (rotating, bad SSD, good SSD, USB flash, holographic cube, electron spin, etc.). -- Dmitri Nikulin Centre for Synchrotron Science Monash University Victoria 3800, Australia -- 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
Hi, While this sounds nice in practice, in reality since eraseblocks are generally very large, and with hardware based block remapping (FTL), you can never be sure which data blocks are at risk when re-writing just one block. There is a good chance that rewriting one block of data somewhere will wipe out a block of data at a totally different location of the disk. Since the filesystem has no understanding of the hardware FTL, there isn''t much that can be done about this at the filesystem level. The only thing that could be done is metadata mirroring on the same disk, but I suspect even that would only marginally improve reliability, since both copies of the metadata are likely to be written to storage at nearly the same time, they are quite likely to be re-mapped into the same block, and then if you loose one, you loose both. The solution to this is twofold: 1 :- filesystems should be able to detect when a non-atomic write has corrupted the filesystem and tell the user - eg. "Filesystem corruption found, Likley hardware malfunction detected" (since with a fs like btrfs, when all big software bugs are resolved, the only thing that can cause disk corruption are hardware issues) 2 :- Someone who feels this is close to their heart needs to test every big brand of SSD and name and shame those where writes are non-atomic - as soon as you get this publicised that certain brands of SSD put data at risk, the manufacturer will be very fast at resolving it. ----- Original Message ----- From: "Seth Huang" <seth.hg@gmail.com> To: <linux-btrfs@vger.kernel.org> Sent: Monday, February 23, 2009 3:17 AM Subject: Re: ssd optimised mode> On Mon, Feb 23, 2009 at 12:22 PM, Dongjun Shin <djshin90@gmail.com> wrote: >> A well-designed SSD should survive power cycling and should provide >> atomicity >> of flush operation regardless of the underlying flash operations. I don''t >> expect >> that users of SSD have different requirements about atomicity. > > A reliable system should be based on the assumption that the underlying > parts are unreliable. Therefore, we should do as much as possible to make > sure the reliability in our filesystem instead of leaning on the SSDs. > > -- > Seth Huang > > -- > 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 > > -- > 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 >-- 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 Sun, 2009-02-22 at 12:07 +1100, Dmitri Nikulin wrote:> On Sat, Feb 21, 2009 at 3:30 AM, Chris Mason <chris.mason@oracle.com> wrote: > > The short answer is that in ssd mode we don''t try to avoid random reads. > > In the ideal future where SSDs can be run without a flimsy hardware > FTL, and btrfs can use something like ubi directly, would SSD mode > also be able to enable more intelligent wear levelling and safer use > of eraseblocks?I think this kind of future is less and less likely. SSD makers are going to differentiate themselves via their FTL, and they are not going to give the OS the chance to mess around with the flash directly. There will surely be exceptions, but I don''t think we''re going to find them in a dell any time soon.> > I''ve read that one of the potentially crippling limitations of ZFS is > that even its reliability features depend largely on being able to > perform atomic writes, which are currently impossible (?) on flash > media where a block has to be erased before it can be updated, clearly > not an atomic operation. Is there any solution to this that doesn''t > depend on a battery backup? Clearly it''s not something a filesystem > can practically solve.I''m sure that some early flash drives got this wrong, but the crummy drives will eventually drop out of the market as the reliable ones gain traction. -chris -- 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
>>>>> "Dmitri" == Dmitri Nikulin <dnikulin@gmail.com> writes:Dmitri> That''s excellent, but until consumer-level drives have the same Dmitri> feature, the fact remains that consumer SSDs are a net loss in Dmitri> reliability compared to consumer rotating disks, My SSD testing has not been very promising in the data integrity department. I''ve got a couple of drives here which end up corrupting stuff every time they are reset or lose power. "Stuff" in this case is on the order of megabytes, not a few sectors like on spinning media. With disk drives the risk of garbling unrelated files is there but relatively small. On SSDs it''s much higher because of the big blocking and the high latency erase/rewrite cycle. In several cases I''ve lost system binaries that obviously weren''t being written when I crashed the system. In one case I even lost all of /sbin. Dmitri> I''m just curious if there''s anything that can be done in a Dmitri> filesystem to minimise the damage of a lost eraseblock. The problem is that we have no way of knowing what''s inside each erase block. We don''t even know how big the erase block is. -- Martin K. Petersen Oracle Linux Engineering -- 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 Monday 23 February 2009, Martin K. Petersen wrote:> "Stuff" in this case is on the order of megabytes, not a few sectors > like on spinning media. With disk drives the risk of garbling unrelated > files is there but relatively small. On SSDs it''s much higher because > of the big blocking and the high latency erase/rewrite cycle. In > several cases I''ve lost system binaries that obviously weren''t being > written when I crashed the system. In one case I even lost all of > /sbin. >What brand of SSDs are we talking about? What filesystems did you experiment with? Best regards Cláudio -- 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
>>>>> "Claudio" == Claudio Martins <ctpm@ist.utl.pt> writes:Claudio> What brand of SSDs are we talking about? I tested two different products that both exhibited poor behavior during frequent resets/power cycles. I can''t really disclose details but rest assured I''m working with the vendors in question to get this fixed. Just last Friday I received a couple of updated drives that appear to work correctly. But I haven''t tested them extensively yet. Claudio> What filesystems did you experiment with? Some tests were done with ext3 but most tests were done using my own integrity checking tooling and/or dt. In the filesystem case it was trivial to map out the affected files in debugfs and correlate those to a logical region on the disk. -- Martin K. Petersen Oracle Linux Engineering -- 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
Dmitri Nikulin wrote:> In the ideal future where SSDs can be run without a flimsy hardware > FTLI don''t think this is likely at all for the same reasons Chris gave.> I''ve read that one of the potentially crippling limitations of ZFS is > that even its reliability features depend largely on being able to > perform atomic writes, which are currently impossible (?) on flash > media where a block has to be erased before it can be updated, clearly > not an atomic operation. Is there any solution to this that doesn''t > depend on a battery backup?A COW write to a pre-erased block should be atomic. See TxFlash: http://storagemojo.com/2009/01/17/transflash/ Wes Felter - wesley@felter.org -- 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 Tue, Feb 24, 2009 at 1:33 AM, Chris Mason <chris.mason@oracle.com> wrote:> On Sun, 2009-02-22 at 12:07 +1100, Dmitri Nikulin wrote: >> On Sat, Feb 21, 2009 at 3:30 AM, Chris Mason <chris.mason@oracle.com> wrote: >> > The short answer is that in ssd mode we don''t try to avoid random reads. >> >> In the ideal future where SSDs can be run without a flimsy hardware >> FTL, and btrfs can use something like ubi directly, would SSD mode >> also be able to enable more intelligent wear levelling and safer use >> of eraseblocks? > > I think this kind of future is less and less likely. SSD makers are > going to differentiate themselves via their FTL, and they are not going > to give the OS the chance to mess around with the flash directly. > > There will surely be exceptions, but I don''t think we''re going to find > them in a dell any time soon.Already SanDisk are offering a proprietary "Extreme FFS" (perhaps even based on Unix FFS) for Windows Vista only. http://www.technewsworld.com/story/65072.html?wlc=1235097496&wlc=1235434234 It is not clear whether this is purely a filesystem which could work on any SSD, but I think it is much more likely it has an FTL bypass that lets it get higher performance than any FTLed filesystem. <RMS>It is proprietary from the ground up and products like these could undo the decades of standardisation and interoperability that have made hard disks and their controllers a commodity. </RMS>> I''m sure that some early flash drives got this wrong, but the crummy > drives will eventually drop out of the market as the reliable ones gain > traction.I''m glad to see this is the trend. I would like nothing more than to not have to care about the SSD being an SSD. Right now it seems you do have to care to get good performance and longevity, but if you can just treat them as a regular disk for the most part, that is a very valuable product even worth the exorbitant price tags. Personally I''m happy as long as I can make one big PV (or RAID0 then a PV) and have that perform well with minimum tweaking. If I can use btrfs as a RAID and volume manager and have that perform even better on the SSD, all the better :) -- Dmitri Nikulin Centre for Synchrotron Science Monash University Victoria 3800, Australia -- 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 Tue, Feb 24, 2009 at 9:16 AM, Dmitri Nikulin <dnikulin@gmail.com> wrote:> > Already SanDisk are offering a proprietary "Extreme FFS" (perhaps even > based on Unix FFS) for Windows Vista only. > http://www.technewsworld.com/story/65072.html?wlc=1235097496&wlc=1235434234 > It is not clear whether this is purely a filesystem which could work > on any SSD, but I think it is much more likely it has an FTL bypass > that lets it get higher performance than any FTLed filesystem. <RMS>It > is proprietary from the ground up and products like these could undo > the decades of standardisation and interoperability that have made > hard disks and their controllers a commodity. </RMS> >I heard that ExtremeFFS is a firmware or FTL technology although it sounds like a filesystem. -- Dongjun -- 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
>>>>> "Dmitri" == Dmitri Nikulin <dnikulin@gmail.com> writes:Dmitri> Already SanDisk are offering a proprietary "Extreme FFS" Dmitri> (perhaps even based on Unix FFS) for Windows Vista only. Extreme FFS is SanDisk''s next generation FTL/firmware. It''s not a filesystem that plugs into the OS. -- Martin K. Petersen Oracle Linux Engineering -- 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 Tue, Feb 24, 2009 at 1:32 PM, Martin K. Petersen <martin.petersen@oracle.com> wrote:>>>>>> "Dmitri" == Dmitri Nikulin <dnikulin@gmail.com> writes: > > Dmitri> Already SanDisk are offering a proprietary "Extreme FFS" > Dmitri> (perhaps even based on Unix FFS) for Windows Vista only. > > Extreme FFS is SanDisk''s next generation FTL/firmware. It''s not a > filesystem that plugs into the OS.If that''s the case, why is it marketed for Windows Vista only, and referring to filesystem features like marking unused blocks? Surely if it was at the device level it would be OS-neutral, and marketed as such. -- Dmitri Nikulin Centre for Synchrotron Science Monash University Victoria 3800, Australia -- 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 Tue, Feb 24, 2009 at 12:53 PM, Dmitri Nikulin <dnikulin@gmail.com> wrote:> On Tue, Feb 24, 2009 at 1:32 PM, Martin K. Petersen > <martin.petersen@oracle.com> wrote: >>>>>>> "Dmitri" == Dmitri Nikulin <dnikulin@gmail.com> writes: >> >> Dmitri> Already SanDisk are offering a proprietary "Extreme FFS" >> Dmitri> (perhaps even based on Unix FFS) for Windows Vista only. >> >> Extreme FFS is SanDisk''s next generation FTL/firmware. It''s not a >> filesystem that plugs into the OS. > > If that''s the case, why is it marketed for Windows Vista only, and > referring to filesystem features like marking unused blocks? Surely if > it was at the device level it would be OS-neutral, and marketed as > such. >It''s marketed for Windows 7 and Windows 7 has feature that send down trim/discard info to the storage. Anyway, Linux support for trim is under way [1]. -- Dongjun [1] http://git.kernel.org/?p=linux/kernel/git/willy/ssd.git;a=shortlog;h=trim-20090212 -- 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
>>>>> "Dmitri" == Dmitri Nikulin <dnikulin@gmail.com> writes:Dmitri> If that''s the case, why is it marketed for Windows Vista only, Dmitri> and referring to filesystem features like marking unused blocks? Dmitri> Surely if it was at the device level it would be OS-neutral, and Dmitri> marketed as such. The article you posted references some benchmarketing numbers involving Vista. That does not imply it''s a Windows-only product. http://en.wikipedia.org/wiki/ExtremeFFS -- Martin K. Petersen Oracle Linux Engineering -- 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 Tue, Feb 24, 2009 at 3:10 PM, Martin K. Petersen <martin.petersen@oracle.com> wrote:>>>>>> "Dmitri" == Dmitri Nikulin <dnikulin@gmail.com> writes: > > Dmitri> If that''s the case, why is it marketed for Windows Vista only, > Dmitri> and referring to filesystem features like marking unused blocks? > Dmitri> Surely if it was at the device level it would be OS-neutral, and > Dmitri> marketed as such. > > The article you posted references some benchmarketing numbers involving > Vista. That does not imply it''s a Windows-only product. > > http://en.wikipedia.org/wiki/ExtremeFFSSo it seems. I misread the marketing material, and I''m very relieved that Linux will benefit just as much from the improvement, indeed probably better. Thank you very much for correcting me, Martin and Dongjun. -- Dmitri Nikulin Centre for Synchrotron Science Monash University Victoria 3800, Australia -- 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