TRIM support

TRIM support

[Leonidas Spyropoulos]

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.

Re: TRIM support

[Calvin Walton]

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>

Re: TRIM support

[Leonidas Spyropoulos]

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.

Re: TRIM support

[Hubert Kario]

On Sunday 03 of July 2011 00:40:46 Leonidas Spyropoulos wrote:
> On Sat, Jul 2, 2011 at 11:39 PM, Leonidas Spyropoulos
>=20
> <artafinde@gmail.com> wrote:
> > On Sat, Jul 2, 2011 at 8:45 PM, Calvin Walton <calvin.walton@kepsti=
n.ca>=20
wrote:
> >> On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote:
> >>> Hello,
> >>>=20
> >>> 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 en=
able
> >>> TRIM.
> >>>=20
> >>> I would like to ask by using ssd mount parameter would TRIM be en=
abled?
> >>> The SSD is Intel 320 Series 120Gb
> >>=20
> >> No, the "ssd" mount parameter has nothing to do with TRIM.
> >>=20
> >> The "ssd" mount parameter adjusts a couple of tuning parameters wh=
ere
> >> the default setting is designed to improve performance on spinning=
 HDD,
> >> and instead tunes for the random-access ability of an SSD.
> >>=20
> >> The ssd option is automatically enabled if the kernel detects that=
 your
> >> drive is an SSD (you can check with 'cat /proc/mounts').
> >>=20
> >> 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.
> >>=20
> >> --
> >> Calvin Walton <calvin.walton@kepstin.ca>
>=20
> On the same system when I try to compile the btrfs-tools I get an err=
or.
> Since on the wiki you mention only the packages for Fedora and Debian=
,
>=20
> Which are the requirements for the btrfs tools?
>=20
> PS: AUR package is broken as well.

the AUR package is OK, problem is that the sources don't compile with n=
ew gcc.

Download Hugo's integration branch
http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-2=
0110630
and apply my patch to it:
http://www.spinics.net/lists/linux-btrfs/msg10965.html
--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=F3w 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

Re: TRIM support

[Leonidas Spyropoulos]

[-- Attachment #1: Type: text/plain, Size: 3013 bytes --]

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?


-- 
Caution: breathing may be hazardous to your health.

[-- Attachment #2: rem.diff --]
[-- Type: text/x-patch, Size: 1478 bytes --]

 mkfs.c    |    3 ---
 volumes.c |    2 --
 2 files changed, 0 insertions(+), 5 deletions(-)

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 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 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++;
       }

Re: TRIM support

[Hubert Kario]

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
> >>=20
> >> <artafinde@gmail.com> wrote:
> >> > On Sat, Jul 2, 2011 at 8:45 PM, Calvin Walton
> >> > <calvin.walton@kepstin.ca>
> >=20
> > wrote:
> >> >> On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote:
> >> >>> Hello,
> >> >>>=20
> >> >>> I just installed an archlinux with btrfs root partition and wo=
uld
> >> >>> 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.
> >> >>>=20
> >> >>> I would like to ask by using ssd mount parameter would TRIM be
> >> >>> enabled? The SSD is Intel 320 Series 120Gb
> >> >>=20
> >> >> No, the "ssd" mount parameter has nothing to do with TRIM.
> >> >>=20
> >> >> The "ssd" mount parameter adjusts a couple of tuning parameters=
 where
> >> >> the default setting is designed to improve performance on spinn=
ing
> >> >> HDD, and instead tunes for the random-access ability of an SSD.
> >> >>=20
> >> >> The ssd option is automatically enabled if the kernel detects t=
hat
> >> >> your drive is an SSD (you can check with 'cat /proc/mounts').
> >> >>=20
> >> >> The discard option is not currently automatically enabled; I th=
ink
> >> >> there may have been some performance issues in certain cases wi=
th
> >> >> drives that have slow trim implementations. But feel free to gi=
ve it
> >> >> a try.
> >> >>=20
> >> >> --
> >> >> Calvin Walton <calvin.walton@kepstin.ca>
> >>=20
> >> 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 Deb=
ian,
> >>=20
> >> Which are the requirements for the btrfs tools?
> >>=20
> >> PS: AUR package is broken as well.
> >=20
> > the AUR package is OK, problem is that the sources don't compile wi=
th new
> > gcc.
> >=20
> > Download Hugo's integration branch
> > http://git.darksatanic.net/repo/btrfs-progs-unstable.git/
> > integration-20110630
>=20
> I download the files:
>=20
> git clone  http://git.darksatanic.net/repo/btrfs-progs-unstable.git/
> integration-20110630
>=20
> > and apply my patch to it:
> > http://www.spinics.net/lists/linux-btrfs/msg10965.html
>=20
> Then I tried to apply the patch you mentioned:
>=20
> patch < rem.diff
>=20
> but it's failing:
> The rem.diff is the file attached
>=20
> > --
> > Hubert Kario
> > QBS - Quality Business Software
> > 02-656 Warszawa, ul. Ksawer=F3w 30/85
> > tel. +48 (22) 646-61-51, 646-74-24
> > www.qbs.com.pl
>=20
> 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
>=20
> 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.
=46ollowing one should apply cleanly

try this:

git clone  http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ in=
tegration-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 bt=
rfs_root *root, int out_fd)
 	struct btrfs_trans_handle *trans;
=20
 	struct stat root_st;
-	int root_len;
=20
 	struct directory_name_entry dir_head;
=20
@@ -1070,8 +1069,6 @@ static int make_image(char *source_dir, struct bt=
rfs_root *root, int out_fd)
 		goto fail;
 	}
=20
-	root_len =3D strlen(source_dir);
-
 	INIT_LIST_HEAD(&dir_head.list);
=20
 	trans =3D 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_handl=
e *trans,
 	struct list_head *dev_list =3D &extent_root->fs_info->fs_devices->dev=
ices;
 	struct list_head *cur;
 	struct map_lookup *map;
-	u64 physical;
 	u64 calc_size =3D 8 * 1024 * 1024;
 	int num_stripes =3D 1;
 	int sub_stripes =3D 0;
@@ -940,7 +939,6 @@ int btrfs_alloc_data_chunk(struct btrfs_trans_handl=
e *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 =3D dev_offset;
 		index++;
 	}
=20
--=20
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

Fwd: TRIM support

[Leonidas Spyropoulos]

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 w=
ould
>> >> >>> 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 t=
o
>> >> >>> enable TRIM.
>> >> >>>
>> >> >>> I would like to ask by using ssd mount parameter would TRIM b=
e
>> >> >>> 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 parameter=
s where
>> >> >> the default setting is designed to improve performance on spin=
ning
>> >> >> HDD, and instead tunes for the random-access ability of an SSD=
=2E
>> >> >>
>> >> >> 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 t=
hink
>> >> >> there may have been some performance issues in certain cases w=
ith
>> >> >> drives that have slow trim implementations. But feel free to g=
ive 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 De=
bian,
>> >>
>> >> 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 w=
ith new
>> > gcc.
>> >
>> > Download Hugo's integration branch
>> > http://git.darksatanic.net/repo/btrfs-progs-unstable.git/
>> > integration-20110630
>>
>> I download the files:
>>
>> git clone =A0http://git.darksatanic.net/repo/btrfs-progs-unstable.gi=
t/
>> 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=F3w 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
=A0 =A0 =A0 =A0struct btrfs_trans_handle *trans;

=A0 =A0 =A0 =A0struct stat root_st;
- =A0 =A0 =A0 int root_len;

=A0 =A0 =A0 =A0struct directory_name_entry dir_head;

@@ -1070,8 +1069,6 @@ static int make_image(char *source_dir, struct
btrfs_root *root, int
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto fail;
=A0 =A0 =A0 =A0}

- =A0 =A0 =A0 root_len =3D strlen(source_dir);
-
=A0 =A0 =A0 =A0INIT_LIST_HEAD(&dir_head.list);

=A0 =A0 =A0 =A0trans =3D 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_handl=
e *trans,
=A0 =A0 =A0 =A0struct list_head *dev_list =3D &extent_root->fs_info->fs=
_devices->devices;
=A0 =A0 =A0 =A0struct list_head *cur;
=A0 =A0 =A0 =A0struct map_lookup *map;
- =A0 =A0 =A0 u64 physical;
=A0 =A0 =A0 =A0u64 calc_size =3D 8 * 1024 * 1024;
=A0 =A0 =A0 =A0int num_stripes =3D 1;
=A0 =A0 =A0 =A0int sub_stripes =3D 0;
@@ -920,7 +919,6 @@ int btrfs_alloc_data_chunk(struct btrfs_trans_handl=
e *trans,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0btrfs_set_stack_stripe_devid(stripe, dev=
ice->devid);
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0btrfs_set_stack_stripe_offset(stripe, de=
v_offset);
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0memcpy(stripe->dev_uuid, device->uuid, B=
TRFS_UUID_SIZE);
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 physical =3D dev_offset;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0index++;
=A0 =A0 =A0 =A0}

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

Re: TRIM support

[Martin Steigerwald]

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

Re: TRIM support

[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 ena=
ble
>> > 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 dur=
ing 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 / =A00,00s user 0,36s system 10% cpu 3,486 total
>
> merkaba:~> time fstrim -v /home
> /home: 27062587392 bytes was trimmed
> fstrim -v /home =A00,00s user 0,92s system 20% cpu 4,512 total
>
> First one is BTRFS, second one is Ext4 - and will be, until I am conv=
inced
> 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 =A0B82F 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 =A0http://vger.kernel.org/majordomo-info.html
>



--=20
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

Re: TRIM support

[Martin Steigerwald]

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

Re: TRIM support

[Chris Samuel]

[-- Attachment #1: Type: Text/Plain, Size: 653 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

Re: TRIM support

[Leonidas Spyropoulos]

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
> --
> =A0Chris Samuel =A0: =A0http://www.csamuel.org/ =A0: =A0Melbourne, VI=
C
>
> This email may come with a PGP signature as a file. Do not panic.
> For more info see: http://en.wikipedia.org/wiki/OpenPGP
>



--=20
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

Re: TRIM support

[Fajar A. Nugraha]

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

Re: TRIM support

[Leonidas Spyropoulos]

So any clues for the intel 320 series? I think it doesn't use compressi=
on.

On Sun, Jul 10, 2011 at 10:59 PM, Fajar A. Nugraha <list@fajar.net> wro=
te:
> 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> wr=
ote:
>>> 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=
=2E
> 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 discar=
d
> (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 =A0http://vger.kernel.org/majordomo-info.html
>



--=20
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

Re: TRIM support

[Chris Samuel]

[-- Attachment #1: Type: Text/Plain, Size: 574 bytes --]

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,
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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

Re: TRIM support

[Fajar A. Nugraha]

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)

Re: TRIM support

[Leonidas Spyropoulos]

On Mon, Jul 11, 2011 at 7:04 AM, Fajar A. Nugraha <list@fajar.net> wrot=
e:
> 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 compre=
ssion.
>
> 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 speci=
al.
>>> 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 disc=
ard
>>> (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 =A0http://vger.kernel.org/majordomo-info.html
>



--=20
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

Re: TRIM support

[Ric Wheeler]

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,
> Chris

How 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

Re: TRIM support

[Fajar A. Nugraha]

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