Hello, I just installed an archlinux with btrfs root partition and would like to set the correct mount properties Following this: https://wiki.archlinux.org/index.php/Solid_State_Drives it says there that I should use the discard mount parameter to enable TRIM. I would like to ask by using ssd mount parameter would TRIM be enabled? The SSD is Intel 320 Series 120Gb Thanks Leonidas -- Caution: breathing may be hazardous to your health. -- 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, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote:> Hello, > > I just installed an archlinux with btrfs root partition and would like > to set the correct mount properties > Following this: > https://wiki.archlinux.org/index.php/Solid_State_Drives > it says there that I should use the discard mount parameter to enable TRIM. > > I would like to ask by using ssd mount parameter would TRIM be enabled? > The SSD is Intel 320 Series 120GbNo, the "ssd" mount parameter has nothing to do with TRIM. The "ssd" mount parameter adjusts a couple of tuning parameters where the default setting is designed to improve performance on spinning HDD, and instead tunes for the random-access ability of an SSD. The ssd option is automatically enabled if the kernel detects that your drive is an SSD (you can check with ''cat /proc/mounts''). The discard option is not currently automatically enabled; I think there may have been some performance issues in certain cases with drives that have slow trim implementations. But feel free to give it a try. -- 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
On Sat, Jul 2, 2011 at 11:39 PM, Leonidas Spyropoulos <artafinde@gmail.com> wrote:> On Sat, Jul 2, 2011 at 8:45 PM, Calvin Walton <calvin.walton@kepstin.ca> wrote: >> On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote: >>> Hello, >>> >>> I just installed an archlinux with btrfs root partition and would like >>> to set the correct mount properties >>> Following this: >>> https://wiki.archlinux.org/index.php/Solid_State_Drives >>> it says there that I should use the discard mount parameter to enable TRIM. >>> >>> I would like to ask by using ssd mount parameter would TRIM be enabled? >>> The SSD is Intel 320 Series 120Gb >> >> No, the "ssd" mount parameter has nothing to do with TRIM. >> >> The "ssd" mount parameter adjusts a couple of tuning parameters where >> the default setting is designed to improve performance on spinning HDD, >> and instead tunes for the random-access ability of an SSD. >> >> The ssd option is automatically enabled if the kernel detects that your >> drive is an SSD (you can check with ''cat /proc/mounts''). >> >> The discard option is not currently automatically enabled; I think there >> may have been some performance issues in certain cases with drives that >> have slow trim implementations. But feel free to give it a try. >> >> -- >> Calvin Walton <calvin.walton@kepstin.ca> >> >>On the same system when I try to compile the btrfs-tools I get an error. Since on the wiki you mention only the packages for Fedora and Debian, Which are the requirements for the btrfs tools? PS: AUR package is broken as well. -- Caution: breathing may be hazardous to your health. -- 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 Sunday 03 of July 2011 00:40:46 Leonidas Spyropoulos wrote:> On Sat, Jul 2, 2011 at 11:39 PM, Leonidas Spyropoulos > > <artafinde@gmail.com> wrote: > > On Sat, Jul 2, 2011 at 8:45 PM, Calvin Walton <calvin.walton@kepstin.ca>wrote:> >> On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote: > >>> Hello, > >>> > >>> I just installed an archlinux with btrfs root partition and would like > >>> to set the correct mount properties > >>> Following this: > >>> https://wiki.archlinux.org/index.php/Solid_State_Drives > >>> it says there that I should use the discard mount parameter to enable > >>> TRIM. > >>> > >>> I would like to ask by using ssd mount parameter would TRIM be enabled? > >>> The SSD is Intel 320 Series 120Gb > >> > >> No, the "ssd" mount parameter has nothing to do with TRIM. > >> > >> The "ssd" mount parameter adjusts a couple of tuning parameters where > >> the default setting is designed to improve performance on spinning HDD, > >> and instead tunes for the random-access ability of an SSD. > >> > >> The ssd option is automatically enabled if the kernel detects that your > >> drive is an SSD (you can check with ''cat /proc/mounts''). > >> > >> The discard option is not currently automatically enabled; I think there > >> may have been some performance issues in certain cases with drives that > >> have slow trim implementations. But feel free to give it a try. > >> > >> -- > >> Calvin Walton <calvin.walton@kepstin.ca> > > On the same system when I try to compile the btrfs-tools I get an error. > Since on the wiki you mention only the packages for Fedora and Debian, > > Which are the requirements for the btrfs tools? > > PS: AUR package is broken as well.the AUR package is OK, problem is that the sources don''t compile with new gcc. Download Hugo''s integration branch http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20110630 and apply my patch to it: http://www.spinics.net/lists/linux-btrfs/msg10965.html -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl -- 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, Jul 3, 2011 at 1:20 PM, Hubert Kario <hka@qbs.com.pl> wrote:> On Sunday 03 of July 2011 00:40:46 Leonidas Spyropoulos wrote: >> On Sat, Jul 2, 2011 at 11:39 PM, Leonidas Spyropoulos >> >> <artafinde@gmail.com> wrote: >> > On Sat, Jul 2, 2011 at 8:45 PM, Calvin Walton <calvin.walton@kepstin.ca> > wrote: >> >> On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote: >> >>> Hello, >> >>> >> >>> I just installed an archlinux with btrfs root partition and would like >> >>> to set the correct mount properties >> >>> Following this: >> >>> https://wiki.archlinux.org/index.php/Solid_State_Drives >> >>> it says there that I should use the discard mount parameter to enable >> >>> TRIM. >> >>> >> >>> I would like to ask by using ssd mount parameter would TRIM be enabled? >> >>> The SSD is Intel 320 Series 120Gb >> >> >> >> No, the "ssd" mount parameter has nothing to do with TRIM. >> >> >> >> The "ssd" mount parameter adjusts a couple of tuning parameters where >> >> the default setting is designed to improve performance on spinning HDD, >> >> and instead tunes for the random-access ability of an SSD. >> >> >> >> The ssd option is automatically enabled if the kernel detects that your >> >> drive is an SSD (you can check with ''cat /proc/mounts''). >> >> >> >> The discard option is not currently automatically enabled; I think there >> >> may have been some performance issues in certain cases with drives that >> >> have slow trim implementations. But feel free to give it a try. >> >> >> >> -- >> >> Calvin Walton <calvin.walton@kepstin.ca> >> >> On the same system when I try to compile the btrfs-tools I get an error. >> Since on the wiki you mention only the packages for Fedora and Debian, >> >> Which are the requirements for the btrfs tools? >> >> PS: AUR package is broken as well. > > the AUR package is OK, problem is that the sources don''t compile with new gcc. > > Download Hugo''s integration branch > http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20110630I download the files: git clone http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20110630> and apply my patch to it: > http://www.spinics.net/lists/linux-btrfs/msg10965.htmlThen I tried to apply the patch you mentioned: patch < rem.diff but it''s failing: The rem.diff is the file attached> -- > Hubert Kario > QBS - Quality Business Software > 02-656 Warszawa, ul. Ksawerów 30/85 > tel. +48 (22) 646-61-51, 646-74-24 > www.qbs.com.pl >Here is the error I am getting: patching file mkfs.c Hunk #1 FAILED at 1060. Hunk #2 FAILED at 1070. 2 out of 2 hunks FAILED -- saving rejects to file mkfs.c.rej patching file volumes.c Hunk #1 FAILED at 868. Hunk #2 FAILED at 920. 2 out of 2 hunks FAILED -- saving rejects to file volumes.c.rej I think the file I created is wrong. What is the accepted format for the patch command? -- Caution: breathing may be hazardous to your health.
On Sunday 03 of July 2011 14:56:40 Leonidas Spyropoulos wrote:> On Sun, Jul 3, 2011 at 1:20 PM, Hubert Kario <hka@qbs.com.pl> wrote: > > On Sunday 03 of July 2011 00:40:46 Leonidas Spyropoulos wrote: > >> On Sat, Jul 2, 2011 at 11:39 PM, Leonidas Spyropoulos > >> > >> <artafinde@gmail.com> wrote: > >> > On Sat, Jul 2, 2011 at 8:45 PM, Calvin Walton > >> > <calvin.walton@kepstin.ca> > > > > wrote: > >> >> On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote: > >> >>> Hello, > >> >>> > >> >>> I just installed an archlinux with btrfs root partition and would > >> >>> like to set the correct mount properties > >> >>> Following this: > >> >>> https://wiki.archlinux.org/index.php/Solid_State_Drives > >> >>> it says there that I should use the discard mount parameter to > >> >>> enable TRIM. > >> >>> > >> >>> I would like to ask by using ssd mount parameter would TRIM be > >> >>> enabled? The SSD is Intel 320 Series 120Gb > >> >> > >> >> No, the "ssd" mount parameter has nothing to do with TRIM. > >> >> > >> >> The "ssd" mount parameter adjusts a couple of tuning parameters where > >> >> the default setting is designed to improve performance on spinning > >> >> HDD, and instead tunes for the random-access ability of an SSD. > >> >> > >> >> The ssd option is automatically enabled if the kernel detects that > >> >> your drive is an SSD (you can check with ''cat /proc/mounts''). > >> >> > >> >> The discard option is not currently automatically enabled; I think > >> >> there may have been some performance issues in certain cases with > >> >> drives that have slow trim implementations. But feel free to give it > >> >> a try. > >> >> > >> >> -- > >> >> Calvin Walton <calvin.walton@kepstin.ca> > >> > >> On the same system when I try to compile the btrfs-tools I get an error. > >> Since on the wiki you mention only the packages for Fedora and Debian, > >> > >> Which are the requirements for the btrfs tools? > >> > >> PS: AUR package is broken as well. > > > > the AUR package is OK, problem is that the sources don''t compile with new > > gcc. > > > > Download Hugo''s integration branch > > http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ > > integration-20110630 > > I download the files: > > git clone http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ > integration-20110630 > > > and apply my patch to it: > > http://www.spinics.net/lists/linux-btrfs/msg10965.html > > Then I tried to apply the patch you mentioned: > > patch < rem.diff > > but it''s failing: > The rem.diff is the file attached > > > -- > > Hubert Kario > > QBS - Quality Business Software > > 02-656 Warszawa, ul. Ksawerów 30/85 > > tel. +48 (22) 646-61-51, 646-74-24 > > www.qbs.com.pl > > Here is the error I am getting: > patching file mkfs.c > Hunk #1 FAILED at 1060. > Hunk #2 FAILED at 1070. > 2 out of 2 hunks FAILED -- saving rejects to file mkfs.c.rej > patching file volumes.c > Hunk #1 FAILED at 868. > Hunk #2 FAILED at 920. > 2 out of 2 hunks FAILED -- saving rejects to file volumes.c.rej > > I think the file I created is wrong. > What is the accepted format for the patch command?sorry, looks like I changed tabs to spaces while posting. Following one should apply cleanly try this: git clone http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20110630 cd integration-20110630 git checkout integration-20110630 git apply path/to/patch Subject: [PATCH] remove unused variables fixes compilation warnings with gcc 4.6.0 20110429 Signed-off-by: Hubert Kario <kario@wit.edu.pl> --- mkfs.c | 3 --- volumes.c | 2 -- 2 files changed, 0 insertions(+), 5 deletions(-) diff --git a/mkfs.c b/mkfs.c index 3a49bab..152b9da 100644 --- a/mkfs.c +++ b/mkfs.c @@ -1060,7 +1060,6 @@ static int make_image(char *source_dir, struct btrfs_root *root, int out_fd) struct btrfs_trans_handle *trans; struct stat root_st; - int root_len; struct directory_name_entry dir_head; @@ -1070,8 +1069,6 @@ static int make_image(char *source_dir, struct btrfs_root *root, int out_fd) goto fail; } - root_len = strlen(source_dir); - INIT_LIST_HEAD(&dir_head.list); trans = btrfs_start_transaction(root, 1); diff --git a/volumes.c b/volumes.c index 31779b7..f5f752b 100644 --- a/volumes.c +++ b/volumes.c @@ -888,7 +888,6 @@ int btrfs_alloc_data_chunk(struct btrfs_trans_handle *trans, struct list_head *dev_list = &extent_root->fs_info->fs_devices->devices; struct list_head *cur; struct map_lookup *map; - u64 physical; u64 calc_size = 8 * 1024 * 1024; int num_stripes = 1; int sub_stripes = 0; @@ -940,7 +939,6 @@ int btrfs_alloc_data_chunk(struct btrfs_trans_handle *trans, btrfs_set_stack_stripe_devid(stripe, device->devid); btrfs_set_stack_stripe_offset(stripe, dev_offset); memcpy(stripe->dev_uuid, device->uuid, BTRFS_UUID_SIZE); - physical = dev_offset; index++; } -- 1.7.5.1 -- 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, Jul 3, 2011 at 3:54 PM, Hubert Kario <kario@wit.edu.pl> wrote:> On Sunday 03 of July 2011 14:56:40 Leonidas Spyropoulos wrote: >> On Sun, Jul 3, 2011 at 1:20 PM, Hubert Kario <hka@qbs.com.pl> wrote: >> > On Sunday 03 of July 2011 00:40:46 Leonidas Spyropoulos wrote: >> >> On Sat, Jul 2, 2011 at 11:39 PM, Leonidas Spyropoulos >> >> >> >> <artafinde@gmail.com> wrote: >> >> > On Sat, Jul 2, 2011 at 8:45 PM, Calvin Walton >> >> > <calvin.walton@kepstin.ca> >> > >> > wrote: >> >> >> On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote: >> >> >>> Hello, >> >> >>> >> >> >>> I just installed an archlinux with btrfs root partition and would >> >> >>> like to set the correct mount properties >> >> >>> Following this: >> >> >>> https://wiki.archlinux.org/index.php/Solid_State_Drives >> >> >>> it says there that I should use the discard mount parameter to >> >> >>> enable TRIM. >> >> >>> >> >> >>> I would like to ask by using ssd mount parameter would TRIM be >> >> >>> enabled? The SSD is Intel 320 Series 120Gb >> >> >> >> >> >> No, the "ssd" mount parameter has nothing to do with TRIM. >> >> >> >> >> >> The "ssd" mount parameter adjusts a couple of tuning parameters where >> >> >> the default setting is designed to improve performance on spinning >> >> >> HDD, and instead tunes for the random-access ability of an SSD. >> >> >> >> >> >> The ssd option is automatically enabled if the kernel detects that >> >> >> your drive is an SSD (you can check with ''cat /proc/mounts''). >> >> >> >> >> >> The discard option is not currently automatically enabled; I think >> >> >> there may have been some performance issues in certain cases with >> >> >> drives that have slow trim implementations. But feel free to give it >> >> >> a try. >> >> >> >> >> >> -- >> >> >> Calvin Walton <calvin.walton@kepstin.ca> >> >> >> >> On the same system when I try to compile the btrfs-tools I get an error. >> >> Since on the wiki you mention only the packages for Fedora and Debian, >> >> >> >> Which are the requirements for the btrfs tools? >> >> >> >> PS: AUR package is broken as well. >> > >> > the AUR package is OK, problem is that the sources don''t compile with new >> > gcc. >> > >> > Download Hugo''s integration branch >> > http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ >> > integration-20110630 >> >> I download the files: >> >> git clone http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ >> integration-20110630 >> >> > and apply my patch to it: >> > http://www.spinics.net/lists/linux-btrfs/msg10965.html >> >> Then I tried to apply the patch you mentioned: >> >> patch < rem.diff >> >> but it''s failing: >> The rem.diff is the file attached >> >> > -- >> > Hubert Kario >> > QBS - Quality Business Software >> > 02-656 Warszawa, ul. Ksawerów 30/85 >> > tel. +48 (22) 646-61-51, 646-74-24 >> > www.qbs.com.pl >> >> Here is the error I am getting: >> patching file mkfs.c >> Hunk #1 FAILED at 1060. >> Hunk #2 FAILED at 1070. >> 2 out of 2 hunks FAILED -- saving rejects to file mkfs.c.rej >> patching file volumes.c >> Hunk #1 FAILED at 868. >> Hunk #2 FAILED at 920. >> 2 out of 2 hunks FAILED -- saving rejects to file volumes.c.rej >> >> I think the file I created is wrong. >> What is the accepted format for the patch command? > > You may also want to try > git checkout integration-20110626 > there were some problems with 20110630 AFAICR > > Hubert >Hey Hubert, Thanks for the suggestions I think I am using the wrong format for the patch. Can you confirm that the patch file named rem.diff should be like the one I attach on the email? I get the same error when trying git apply on both integrations: git apply ../rem.diff error: patch failed: mkfs.c:1060 error: mkfs.c: patch does not apply error: patch failed: volumes.c:888 error: volumes.c: patch does not apply I finally got it to compile the integration-20110626 by manually finding the four lines and deleting them. Here is the git diff --- diff --git a/mkfs.c b/mkfs.c index 1b5ef06..d40b2e8 100644 --- a/mkfs.c +++ b/mkfs.c @@ -1060,7 +1060,6 @@ static int make_image(char *source_dir, struct btrfs_root *root, int struct btrfs_trans_handle *trans; struct stat root_st; - int root_len; struct directory_name_entry dir_head; @@ -1070,8 +1069,6 @@ static int make_image(char *source_dir, struct btrfs_root *root, int goto fail; } - root_len = strlen(source_dir); - INIT_LIST_HEAD(&dir_head.list); trans = btrfs_start_transaction(root, 1); diff --git a/volumes.c b/volumes.c index 61af845..95c2e0d 100644 --- a/volumes.c +++ b/volumes.c @@ -868,7 +868,6 @@ int btrfs_alloc_data_chunk(struct btrfs_trans_handle *trans, struct list_head *dev_list = &extent_root->fs_info->fs_devices->devices; struct list_head *cur; struct map_lookup *map; - u64 physical; u64 calc_size = 8 * 1024 * 1024; int num_stripes = 1; int sub_stripes = 0; @@ -920,7 +919,6 @@ int btrfs_alloc_data_chunk(struct btrfs_trans_handle *trans, btrfs_set_stack_stripe_devid(stripe, device->devid); btrfs_set_stack_stripe_offset(stripe, dev_offset); memcpy(stripe->dev_uuid, device->uuid, BTRFS_UUID_SIZE); - physical = dev_offset; index++; } Thanks for the help Leonidas P.S.: I always forget to Reply to All Sorry for double email Hubert -- Caution: breathing may be hazardous to your health. -- 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 Samstag, 2. Juli 2011 schrieben Sie:> On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote: > > Hello, > > > > I just installed an archlinux with btrfs root partition and would > > like to set the correct mount properties > > Following this: > > https://wiki.archlinux.org/index.php/Solid_State_Drives > > it says there that I should use the discard mount parameter to enable > > TRIM. > > > > I would like to ask by using ssd mount parameter would TRIM be > > enabled? The SSD is Intel 320 Series 120Gb > > No, the "ssd" mount parameter has nothing to do with TRIM.[...]> The discard option is not currently automatically enabled; I think > there may have been some performance issues in certain cases with > drives that have slow trim implementations. But feel free to give it a > try.As alternative use fstrim command from time to time or regularily during a cron job. From what I understood it does batched discard of all free blocks in a filesystem. merkaba:~> time fstrim -v / /: 5044342784 bytes was trimmed fstrim -v / 0,00s user 0,36s system 10% cpu 3,486 total merkaba:~> time fstrim -v /home /home: 27062587392 bytes was trimmed fstrim -v /home 0,00s user 0,92s system 20% cpu 4,512 total First one is BTRFS, second one is Ext4 - and will be, until I am convinced that BTRFS has a fully featured and working fsck and until its experimental flag is removed. fstrim is in util-linux(-ng) when its new enough. -- 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 Mon, Jul 4, 2011 at 5:20 PM, Martin Steigerwald <Martin@lichtvoll.de> wrote:> Am Samstag, 2. Juli 2011 schrieben Sie: >> On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote: >> > Hello, >> > >> > I just installed an archlinux with btrfs root partition and would >> > like to set the correct mount properties >> > Following this: >> > https://wiki.archlinux.org/index.php/Solid_State_Drives >> > it says there that I should use the discard mount parameter to enable >> > TRIM. >> > >> > I would like to ask by using ssd mount parameter would TRIM be >> > enabled? The SSD is Intel 320 Series 120Gb >> >> No, the "ssd" mount parameter has nothing to do with TRIM. > [...] >> The discard option is not currently automatically enabled; I think >> there may have been some performance issues in certain cases with >> drives that have slow trim implementations. But feel free to give it a >> try. > > As alternative use fstrim command from time to time or regularily during a > cron job. From what I understood it does batched discard of all free > blocks in a filesystem. > > merkaba:~> time fstrim -v / > /: 5044342784 bytes was trimmed > fstrim -v / 0,00s user 0,36s system 10% cpu 3,486 total > > merkaba:~> time fstrim -v /home > /home: 27062587392 bytes was trimmed > fstrim -v /home 0,00s user 0,92s system 20% cpu 4,512 total > > First one is BTRFS, second one is Ext4 - and will be, until I am convinced > that BTRFS has a fully featured and working fsck and until its > experimental flag is removed. > > fstrim is in util-linux(-ng) when its new enough.Do I need to run fstrim command while the partition is offline or can it be done while mounted?> > -- > 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 >-- Caution: breathing may be hazardous to your health. -- 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 Montag, 4. Juli 2011 schrieb Leonidas Spyropoulos:> On Mon, Jul 4, 2011 at 5:20 PM, Martin Steigerwald <Martin@lichtvoll.de>wrote:> > Am Samstag, 2. Juli 2011 schrieben Sie: > >> On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote: > >> > Hello, > >> > > >> > I just installed an archlinux with btrfs root partition and would > >> > like to set the correct mount properties > >> > Following this: > >> > https://wiki.archlinux.org/index.php/Solid_State_Drives > >> > it says there that I should use the discard mount parameter to > >> > enable TRIM. > >> > > >> > I would like to ask by using ssd mount parameter would TRIM be > >> > enabled? The SSD is Intel 320 Series 120Gb > >> > >> No, the "ssd" mount parameter has nothing to do with TRIM. > > > > [...] > > > >> The discard option is not currently automatically enabled; I think > >> there may have been some performance issues in certain cases with > >> drives that have slow trim implementations. But feel free to give it > >> a try. > > > > As alternative use fstrim command from time to time or regularily > > during a cron job. From what I understood it does batched discard of > > all free blocks in a filesystem. > > > > merkaba:~> time fstrim -v / > > /: 5044342784 bytes was trimmed > > fstrim -v / 0,00s user 0,36s system 10% cpu 3,486 total > > > > merkaba:~> time fstrim -v /home > > /home: 27062587392 bytes was trimmed > > fstrim -v /home 0,00s user 0,92s system 20% cpu 4,512 total > > > > First one is BTRFS, second one is Ext4 - and will be, until I am > > convinced that BTRFS has a fully featured and working fsck and until > > its experimental flag is removed. > > > > fstrim is in util-linux(-ng) when its new enough. > > Do I need to run fstrim command while the partition is offline or can > it be done while mounted?It is run on a mount point, so I think the filesystem needs to be mounted. They are here. -- 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 Sun, 3 Jul 2011 05:45:17 AM Calvin Walton wrote:> The discard option is not currently automatically enabled; I think > there may have been some performance issues in certain cases with > drives that have slow trim implementations. But feel free to give > it a try.This LWN article from 2009 explains why it can be problematic (especially on SATA drives where TRIM is a non-queued command): https://lwn.net/Articles/347511/ cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP
On Sun, Jul 10, 2011 at 9:33 AM, Chris Samuel <chris@csamuel.org> wrote:> On Sun, 3 Jul 2011 05:45:17 AM Calvin Walton wrote: > >> The discard option is not currently automatically enabled; I think >> there may have been some performance issues in certain cases with >> drives that have slow trim implementations. But feel free to give >> it a try. > > This LWN article from 2009 explains why it can be problematic > (especially on SATA drives where TRIM is a non-queued command): > > https://lwn.net/Articles/347511/ >So the current problem with TRIM in ATA (and SATA) is that it introduce delays? As long as it keeps your SSD in a good shape it''s still better than not having TRIM at all, right? Also the only viable option for now is fstrim? What is fstrim does that kernel cannot? I thought the TRIM was included as from kernel 2.6.29, no ? Cheers Leonidas> cheers, > Chris > -- > Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC > > This email may come with a PGP signature as a file. Do not panic. > For more info see: http://en.wikipedia.org/wiki/OpenPGP >-- Caution: breathing may be hazardous to your health. -- 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, Jul 11, 2011 at 3:58 AM, Leonidas Spyropoulos <artafinde@gmail.com> wrote:> On Sun, Jul 10, 2011 at 9:33 AM, Chris Samuel <chris@csamuel.org> wrote: >> On Sun, 3 Jul 2011 05:45:17 AM Calvin Walton wrote: >> This LWN article from 2009 explains why it can be problematic >> (especially on SATA drives where TRIM is a non-queued command): >> >> https://lwn.net/Articles/347511/ >> > So the current problem with TRIM in ATA (and SATA) is that it > introduce delays? As long as it keeps your SSD in a good shape it''s > still better than not having TRIM at all, right?Not quite. Sandforce-based SSDs have their own way of reducing writes (e.g. by using internal compression), so you don''t have to do anything special. Also, AFAIK currently TRIM is useless if the drives are behind a hardware raid controller anyway. My Corsair F60 (on a notebook) is actually MUCH SLOWER with -o discard (i.e. writes capped at 100 iops) -- Fajar -- 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
So any clues for the intel 320 series? I think it doesn''t use compression. On Sun, Jul 10, 2011 at 10:59 PM, Fajar A. Nugraha <list@fajar.net> wrote:> On Mon, Jul 11, 2011 at 3:58 AM, Leonidas Spyropoulos > <artafinde@gmail.com> wrote: >> On Sun, Jul 10, 2011 at 9:33 AM, Chris Samuel <chris@csamuel.org> wrote: >>> On Sun, 3 Jul 2011 05:45:17 AM Calvin Walton wrote: >>> This LWN article from 2009 explains why it can be problematic >>> (especially on SATA drives where TRIM is a non-queued command): >>> >>> https://lwn.net/Articles/347511/ >>> >> So the current problem with TRIM in ATA (and SATA) is that it >> introduce delays? As long as it keeps your SSD in a good shape it''s >> still better than not having TRIM at all, right? > > Not quite. > > Sandforce-based SSDs have their own way of reducing writes (e.g. by > using internal compression), so you don''t have to do anything special. > Also, AFAIK currently TRIM is useless if the drives are behind a > hardware raid controller anyway. > > My Corsair F60 (on a notebook) is actually MUCH SLOWER with -o discard > (i.e. writes capped at 100 iops) > > -- > Fajar > -- > 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 >-- Caution: breathing may be hazardous to your health. -- 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, 11 Jul 2011 07:59:54 AM Fajar A. Nugraha wrote:> Sandforce-based SSDs have their own way of reducing writes > (e.g. by using internal compression), so you don''t have to > do anything specialNot just compression, but also block level de-duplication too (i.e. potentially removing the redundancy of btrfs''s duplication of metadata for safety). cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP
On Mon, Jul 11, 2011 at 5:34 AM, Leonidas Spyropoulos <artafinde@gmail.com> wrote:> So any clues for the intel 320 series? I think it doesn''t use compression.At this point your best bet is to try it yourself and see. If it doesn''t result in poor performance, then keep on using "-o discard". -- Fajar> > On Sun, Jul 10, 2011 at 10:59 PM, Fajar A. Nugraha <list@fajar.net> wrote: >> On Mon, Jul 11, 2011 at 3:58 AM, Leonidas Spyropoulos >> <artafinde@gmail.com> wrote: >>> On Sun, Jul 10, 2011 at 9:33 AM, Chris Samuel <chris@csamuel.org> wrote: >>>> On Sun, 3 Jul 2011 05:45:17 AM Calvin Walton wrote: >>>> This LWN article from 2009 explains why it can be problematic >>>> (especially on SATA drives where TRIM is a non-queued command): >>>> >>>> https://lwn.net/Articles/347511/ >>>> >>> So the current problem with TRIM in ATA (and SATA) is that it >>> introduce delays? As long as it keeps your SSD in a good shape it''s >>> still better than not having TRIM at all, right? >> >> Not quite. >> >> Sandforce-based SSDs have their own way of reducing writes (e.g. by >> using internal compression), so you don''t have to do anything special. >> Also, AFAIK currently TRIM is useless if the drives are behind a >> hardware raid controller anyway. >> >> My Corsair F60 (on a notebook) is actually MUCH SLOWER with -o discard >> (i.e. writes capped at 100 iops)-- 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, Jul 11, 2011 at 7:04 AM, Fajar A. Nugraha <list@fajar.net> wrote:> On Mon, Jul 11, 2011 at 5:34 AM, Leonidas Spyropoulos > <artafinde@gmail.com> wrote: >> So any clues for the intel 320 series? I think it doesn''t use compression. > > At this point your best bet is to try it yourself and see. If it > doesn''t result in poor performance, then keep on using "-o discard".Could you propose me any tools available for measuring performance? I only know iozone and tunefs -t parameter.> > -- > Fajar > >> >> On Sun, Jul 10, 2011 at 10:59 PM, Fajar A. Nugraha <list@fajar.net> wrote: >>> On Mon, Jul 11, 2011 at 3:58 AM, Leonidas Spyropoulos >>> <artafinde@gmail.com> wrote: >>>> On Sun, Jul 10, 2011 at 9:33 AM, Chris Samuel <chris@csamuel.org> wrote: >>>>> On Sun, 3 Jul 2011 05:45:17 AM Calvin Walton wrote: >>>>> This LWN article from 2009 explains why it can be problematic >>>>> (especially on SATA drives where TRIM is a non-queued command): >>>>> >>>>> https://lwn.net/Articles/347511/ >>>>> >>>> So the current problem with TRIM in ATA (and SATA) is that it >>>> introduce delays? As long as it keeps your SSD in a good shape it''s >>>> still better than not having TRIM at all, right? >>> >>> Not quite. >>> >>> Sandforce-based SSDs have their own way of reducing writes (e.g. by >>> using internal compression), so you don''t have to do anything special. >>> Also, AFAIK currently TRIM is useless if the drives are behind a >>> hardware raid controller anyway. >>> >>> My Corsair F60 (on a notebook) is actually MUCH SLOWER with -o discard >>> (i.e. writes capped at 100 iops) > -- > 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 >-- Caution: breathing may be hazardous to your health. -- 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 07/11/2011 06:53 AM, Chris Samuel wrote:> On Mon, 11 Jul 2011 07:59:54 AM Fajar A. Nugraha wrote: > >> Sandforce-based SSDs have their own way of reducing writes >> (e.g. by using internal compression), so you don''t have to >> do anything special > Not just compression, but also block level de-duplication too > (i.e. potentially removing the redundancy of btrfs''s duplication > of metadata for safety). > > cheers, > ChrisHow vendors implement their internal firmware at any given point is not something that we can know (or should know). As mentioned in this thread, you can and should always measure the performance of your application on your OS with and without discard being enabled. Note that you might have long term effects (i.e., trim enabled via discard might avoid the performance hit you see with some devices after extensive use, especially when full). Keep in mind that discard support is built on an industry standard command and is used by other vendors (including windows) so manufacturers that do a bad job and suffer performance impacts will be *very* motivated to fix their firmware :) Ric -- 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, Jul 11, 2011 at 2:02 PM, Leonidas Spyropoulos <artafinde@gmail.com> wrote:> On Mon, Jul 11, 2011 at 7:04 AM, Fajar A. Nugraha <list@fajar.net> wrote: >> On Mon, Jul 11, 2011 at 5:34 AM, Leonidas Spyropoulos >> <artafinde@gmail.com> wrote: >>> So any clues for the intel 320 series? I think it doesn''t use compression. >> >> At this point your best bet is to try it yourself and see. If it >> doesn''t result in poor performance, then keep on using "-o discard".> Could you propose me any tools available for measuring performance? > > I only know iozone and tunefs -t parameter.Anything that can measure random write IO is fine. I use fio with this jobfile: $ cat randomwrite.fio [write-test] rw=randwrite ioengine=libaio blocksize=4k iodepth=32 size=1G the result: write: io=1024MB, bw=32395KB/s, iops=8098, runt= 32368msec If you still have similar performance with and without "-o discard", then you should add it your mount options. -- Fajar -- 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