read-only subvolumes?

linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

* read-only subvolumes?
@ 2011-03-23  8:21 Andreas Philipp
  2011-03-23  9:01 ` Fajar A. Nugraha
  2011-03-23  9:25 ` Li Zefan
  0 siblings, 2 replies; 7+ messages in thread
From: Andreas Philipp @ 2011-03-23  8:21 UTC (permalink / raw)
  To: linux-btrfs; +Cc: Andreas Philipp


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Hi all,

When I am creating subvolumes I get this strange behavior. If I create
a subvolume with a name longer than 4 characters it is read-only, if
the name is shorter than 5 characters the subvolume is writeable as
expected. I think it is since I upgraded to kernel version 2.6.38 (I
do not create subvolumes on a regular basis.). I will compile one of
the latest 2.6.37 kernels to see whether there the problem exists,
too. Another interesting point is that previously created subvolumes
are not affected.

Thanks,
Andreas Philipp

thor btrfs # btrfs subvolume create 123456789
Create subvolume './123456789'
thor btrfs # touch 123456789/lsdkfj
touch: cannot touch `123456789/lsdkfj': Read-only file system

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJNia2nAAoJEJIcBJ3+XkgiTQQQAJqvn+zYbDmqmSo8ZRG86ssR
Tj0hsaAYjSWiIUxs7Y9XulmC0sZoSpvX5BLIjW1pYwECzhzrA//pQrwVbXgwbW5H
VjZ+YxcOcw4jxoUbW3lG+KYtSFMJFtbdMejmCY3GgYYIq1mtn0hBrCqZJ0syl4LO
IjyTHR/v0r7FMIgL26F1jOfC478RfhIxAgZOtd65kl7/pHOv5At+99tgM4teUoy0
I76CWu6Ls9+1XevxMWp39XNceYCtQ/WoEThuQCvPERq6Th3NWczPBTP3POSBetVA
Kcomq0TmgXQx1ZalFAFpMi9iRriDXbSm3ITSZW6Jp2BSEPurzpydchfhg0AWVNcC
Icp5b+dy2RVM/K5UNDO6lNf8p+K1wk8GGpD/Pr+K0lO0FlKX+6rApzgx54GYL3cx
0RYL+NAAwSpy1i2uBIw72gyGX/yBliX7CB+YZZ/iULk0eUd36FvpJJAJ1Isk+QNn
6WFBoRwsMrL3WfiqR5/ODO+i+z+CUzYU0mUnD9IuQkdCANyXOeQhs5AyMOPkB1NC
SS9ChpL60khwmLs9c99AyIzcvZU/q12JMvOZ2YUnfEHNIC/XmaThq11RbCIWIsl2
vjPr1QvKK+aykaOfjiTgLTwvB3mq147uEAylzIkduiQSFizMudbsI9vcO/X2pcy3
SVO9m6tlBUsCq3dU1dcA
=NEEb
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: read-only subvolumes?
  2011-03-23  8:21 read-only subvolumes? Andreas Philipp
@ 2011-03-23  9:01 ` Fajar A. Nugraha
  2011-03-23  9:25 ` Li Zefan
  1 sibling, 0 replies; 7+ messages in thread
From: Fajar A. Nugraha @ 2011-03-23  9:01 UTC (permalink / raw)
  To: Andreas Philipp; +Cc: linux-btrfs

On Wed, Mar 23, 2011 at 3:21 PM, Andreas Philipp
<philipp.andreas@gmail.com> wrote:
> I think it is since I upgraded to kernel version 2.6.38 (I
> do not create subvolumes on a regular basis.).

> thor btrfs # btrfs subvolume create 123456789
> Create subvolume './123456789'
> thor btrfs # touch 123456789/lsdkfj
> touch: cannot touch `123456789/lsdkfj': Read-only file system

It works on my system

# touch test1
# btrfs su cr 123456789
Create subvolume './123456789'
# touch 123456789/lsdkfj
# uname -a
Linux HP 2.6.38-020638-generic #201103151303 SMP Tue Mar 15 14:33:40
UTC 2011 i686 GNU/Linux

-- 
Fajar

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: read-only subvolumes?
  2011-03-23  8:21 read-only subvolumes? Andreas Philipp
  2011-03-23  9:01 ` Fajar A. Nugraha
@ 2011-03-23  9:25 ` Li Zefan
  2011-03-23 10:07   ` Andreas Philipp
  1 sibling, 1 reply; 7+ messages in thread
From: Li Zefan @ 2011-03-23  9:25 UTC (permalink / raw)
  To: Andreas Philipp; +Cc: linux-btrfs

> Hi all,
> 
> When I am creating subvolumes I get this strange behavior. If I create
> a subvolume with a name longer than 4 characters it is read-only, if
> the name is shorter than 5 characters the subvolume is writeable as
> expected. I think it is since I upgraded to kernel version 2.6.38 (I
> do not create subvolumes on a regular basis.). I will compile one of
> the latest 2.6.37 kernels to see whether there the problem exists,
> too. Another interesting point is that previously created subvolumes
> are not affected.
> 
> Thanks,
> Andreas Philipp
> 
> thor btrfs # btrfs subvolume create 123456789
> Create subvolume './123456789'
> thor btrfs # touch 123456789/lsdkfj
> touch: cannot touch `123456789/lsdkfj': Read-only file system

This is really odd, but I can't reproduce it.

I created a btrfs filesystem on 2.6.37 kernel, and rebooted to latest
2.6.38+, and tried the procedures as you did, but nothing bad happend.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: read-only subvolumes?
  2011-03-23  9:25 ` Li Zefan
@ 2011-03-23 10:07   ` Andreas Philipp
  2011-03-23 10:14     ` Andreas Philipp
  0 siblings, 1 reply; 7+ messages in thread
From: Andreas Philipp @ 2011-03-23 10:07 UTC (permalink / raw)
  To: Li Zefan; +Cc: linux-btrfs, Andreas Philipp


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
On 23.03.2011 10:25, Li Zefan wrote:
>> Hi all,
>>
>> When I am creating subvolumes I get this strange behavior. If I
>> create a subvolume with a name longer than 4 characters it is
>> read-only, if the name is shorter than 5 characters the subvolume
>> is writeable as expected. I think it is since I upgraded to
>> kernel version 2.6.38 (I do not create subvolumes on a regular
>> basis.). I will compile one of the latest 2.6.37 kernels to see
>> whether there the problem exists, too. Another interesting point
>> is that previously created subvolumes are not affected.
>>
>> Thanks, Andreas Philipp
>>
>> thor btrfs # btrfs subvolume create 123456789 Create subvolume
>> './123456789' thor btrfs # touch 123456789/lsdkfj touch: cannot
>> touch `123456789/lsdkfj': Read-only file system
>
> This is really odd, but I can't reproduce it.
>
> I created a btrfs filesystem on 2.6.37 kernel, and rebooted to
> latest 2.6.38+, and tried the procedures as you did, but nothing
> bad happend.
While playing around I found the following three new points:
- - Now the length of the subvolume name does not matter. So even the
ones with short names are read-only.
- - It also happens to a fresh newly created btrfs filesystem.
- - If I take a snapshot of an "old" (= writeable) subvolume this is
writeable.

I will now reboot into 2.6.37.4, check there, and then report back.

Thanks,
Andreas Philipp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJNicZIAAoJEJIcBJ3+XkgiDysP/1oo770VqaEhf3F9gXq5/V3W
AkGGuRb0Upkwie5Y7L3YjCAjAJplYCemncsjqLDQVIQP6iYfmC3bLIM1GjDjMLfT
uwt89/pDte2JStW6kFx0u5i7IwYD6NO7vh3/i7+l1RB4qpZ7DAomroeHS5FFgD2M
y6hZcQ/bhiRKDv82c7YscBVE3ZgKIDPUHoNeduCGsCj8hSd4+/8PR7auGjv42a/l
C92G01cx4mMS0pmnwLUL4U54n1rbJNrKkaoQwINNW/E3fj6gQRwtI1QyDhDWnmfO
Y6c3JRtyYeWGadCaMq4SYGWvSFhG8jlR/a17ozubrLf/An14ywohx1pUZq0fPp9z
oxSlZCINhGBDSeahGQBw7szmU45lXf8N99TgaUTLiHyStnlQfcqpD5RyJUTSBOa2
VAVpMeuvjqw1ng+Tsd1r35e/WBtPQOd9aUj6r5Hcjt4oGlV0mL7oBAR/J0DjNYfl
kii8Ah+NWHFVw/pUVfWC3lzcwfqFIikvn3KVsR2X4LrOTmi6thrh0EG+eSOhfWuf
dI/agqONGzNGH73V7jFtWaEjetrhqRrr5Q22syqWfqX/AYbzTAlISHm574RPtf0G
P2r1fn/s/3FXGKo4zfTsscuvEE4LJaKFrjFxz5mW4wOz9hhFmTBox71ex538ZiMv
NfZzNRKpmXyZCm8USF/i
=b3lE
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: read-only subvolumes?
  2011-03-23 10:07   ` Andreas Philipp
@ 2011-03-23 10:14     ` Andreas Philipp
       [not found]       ` <4D89CBF4.6040600@gmail.com>
  0 siblings, 1 reply; 7+ messages in thread
From: Andreas Philipp @ 2011-03-23 10:14 UTC (permalink / raw)
  To: Andreas Philipp; +Cc: Li Zefan, linux-btrfs


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
On 23.03.2011 11:07, Andreas Philipp wrote:
>
> On 23.03.2011 10:25, Li Zefan wrote:
>>> Hi all,
>>>
>>> When I am creating subvolumes I get this strange behavior. If I
>>> create a subvolume with a name longer than 4 characters it is
>>> read-only, if the name is shorter than 5 characters the
>>> subvolume is writeable as expected. I think it is since I
>>> upgraded to kernel version 2.6.38 (I do not create subvolumes
>>> on a regular basis.). I will compile one of the latest 2.6.37
>>> kernels to see whether there the problem exists, too. Another
>>> interesting point is that previously created subvolumes are
>>> not affected.
>>>
>>> Thanks, Andreas Philipp
>>>
>>> thor btrfs # btrfs subvolume create 123456789 Create subvolume
>>> './123456789' thor btrfs # touch 123456789/lsdkfj touch:
>>> cannot touch `123456789/lsdkfj': Read-only file system
>
>> This is really odd, but I can't reproduce it.
>
>> I created a btrfs filesystem on 2.6.37 kernel, and rebooted to
>> latest 2.6.38+, and tried the procedures as you did, but nothing
>> bad happend.
> While playing around I found the following three new points: - Now
> the length of the subvolume name does not matter. So even the ones
> with short names are read-only. - It also happens to a fresh newly
> created btrfs filesystem. - If I take a snapshot of an "old" (=
> writeable) subvolume this is writeable.
>
> I will now reboot into 2.6.37.4, check there, and then report
> back.

Well, this was fast. Everything works as expected on 2.6.37.4. See the
output of uname -a for the exact kernel version below.
I will now reboot into a differently configured kernel version 2.6.38
and look whether the problem is gone there.

Thanks,
Andreas Philipp

thor ~ # uname -a
Linux thor 2.6.37.4 #2 SMP Wed Mar 23 10:25:54 CET 2011 x86_64
Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJNicgcAAoJEJIcBJ3+XkgiDRwP/jVRcrc+Qwq8D3rE50MjBox0
vy8ZKna2MXO4dl6Et8td1ikL0T91eueIjvOeaU5cS8vxknG7xqGh9k89Nd74j98a
2paWOiR49vYYhcKF1EZm6oKgHri/N/1RfLWvhXJef3POprwz3/n3YZcSDsiXcAnJ
M8RnGgYFoXNGamPorp32rR5XMln9A6Uma+cUZuaL4eitvsZ+YDsYk4XKZ/8O+cql
u5xKihRNDRqQL7LCfqfL0iJxDl3AReOdXUo8sBmo2ioLNv+syJJhhJ2XRbx7r8rM
LDWOnsBE1oCq2QuM49MDxuD4JFhCmTJ6oJotaBShcU0J0S8Dlu1URucDO7P33BOK
qBFnavR3HaUR+MRor7U+LmeYvasmhj/hUa1nx5jvMEQqeTIioQmYLdllyvHGApfy
R4n1+/L91mRr56s96DC31mF7xnSC13LVLJLG+r3ktlj9/u6B+8LAISgo1uDJX681
YQ5KkI8O+5AcAT8Hu1pwdQVC+LXDPp8HIqL59pUWD2v4zyynVqSKgCSKLJ10npLF
+NZRhSb6czNSvM0UrUBXPLq1th+ErfMNn4b6RCrAPbA4T5bejvCUUlkx7FiAMmVx
rnfiyolblNMfQ+9rY9k8zzZeJfR88wx7yS2VoZlV7n68K01GMy+NDRK203TjcX36
+Y8kUmwptiXc48H6teUN
=aSSq
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 7+ messages in thread

[parent not found: <4D89CBF4.6040600@gmail.com>]

* Re: read-only subvolumes?
       [not found]       ` <4D89CBF4.6040600@gmail.com>
@ 2011-03-24  6:30         ` Li Zefan
  2011-03-24  9:31         ` Li Zefan
  1 sibling, 0 replies; 7+ messages in thread
From: Li Zefan @ 2011-03-24  6:30 UTC (permalink / raw)
  To: Andreas Philipp; +Cc: linux-btrfs

>>>>> When I am creating subvolumes I get this strange behavior. If
>>>>> I create a subvolume with a name longer than 4 characters it
>>>>> is read-only, if the name is shorter than 5 characters the
>>>>> subvolume is writeable as expected. I think it is since I
>>>>> upgraded to kernel version 2.6.38 (I do not create
>>>>> subvolumes on a regular basis.). I will compile one of the
>>>>> latest 2.6.37 kernels to see whether there the problem
>>>>> exists, too. Another interesting point is that previously
>>>>> created subvolumes are not affected.
>>>>>
>>>>> Thanks, Andreas Philipp
>>>>>
>>>>> thor btrfs # btrfs subvolume create 123456789 Create
>>>>> subvolume './123456789' thor btrfs # touch 123456789/lsdkfj
>>>>> touch: cannot touch `123456789/lsdkfj': Read-only file
>>>>> system
>>
>>>> This is really odd, but I can't reproduce it.
>>
>>>> I created a btrfs filesystem on 2.6.37 kernel, and rebooted to
>>>> latest 2.6.38+, and tried the procedures as you did, but
>>>> nothing bad happend.
>>> While playing around I found the following three new points: -
>>> Now the length of the subvolume name does not matter. So even the
>>> ones with short names are read-only. - It also happens to a fresh
>>> newly created btrfs filesystem. - If I take a snapshot of an
>>> "old" (= writeable) subvolume this is writeable.
>>
>>> I will now reboot into 2.6.37.4, check there, and then report
>>> back.
>>
>> Well, this was fast. Everything works as expected on 2.6.37.4. See
>> the output of uname -a for the exact kernel version below. I will
>> now reboot into a differently configured kernel version 2.6.38 and
>> look whether the problem is gone there.
>>
>> Thanks, Andreas Philipp
>>
>> thor ~ # uname -a Linux thor 2.6.37.4 #2 SMP Wed Mar 23 10:25:54
>> CET 2011 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel
>> GNU/Linux
> 
> IMHO, this is related to how the debug options of the kernel are
> configured. Attached you find two config files, both for kernel
> version 2.6.38, with the one named 2.6.38-debug everything works and
> with the other one newly created subvolumes are read only.
> 

I'll see if I can reproduce the problem using your config. Thanks!

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: read-only subvolumes?
       [not found]       ` <4D89CBF4.6040600@gmail.com>
  2011-03-24  6:30         ` Li Zefan
@ 2011-03-24  9:31         ` Li Zefan
  1 sibling, 0 replies; 7+ messages in thread
From: Li Zefan @ 2011-03-24  9:31 UTC (permalink / raw)
  To: Andreas Philipp; +Cc: linux-btrfs

> IMHO, this is related to how the debug options of the kernel are
> configured. Attached you find two config files, both for kernel
> version 2.6.38, with the one named 2.6.38-debug everything works and
> with the other one newly created subvolumes are read only.
> 

I've figured out what's wrong.

The root cause is the flags field of the root item for a new subvol
is never _initialized_!! so the on disk root_item->flags can be of
arbitrary value..

(so is root_item->byte_limit btw.)

I don't have a perfect solution at the moment, but I think a workaround
is to use a flag in root_item->inode_item->flags to indicate if
root->flags is initialized.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2011-03-24  9:31 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-23  8:21 read-only subvolumes? Andreas Philipp
2011-03-23  9:01 ` Fajar A. Nugraha
2011-03-23  9:25 ` Li Zefan
2011-03-23 10:07   ` Andreas Philipp
2011-03-23 10:14     ` Andreas Philipp
     [not found]       ` <4D89CBF4.6040600@gmail.com>
2011-03-24  6:30         ` Li Zefan
2011-03-24  9:31         ` Li Zefan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).