How to determine freeze/unfreeze status of a filesystem?
up vote
1
down vote
favorite
I use xfs_freeze
to freeze and unfreeze my xfs filesystem:
xfs_freeze -f /blahblah
xfs_freeze -u /blahblah
After I run the unfreeze command I want to make sure that the filesystem is not frozen for sure. This command does not return any value or message.
I know I can try remounting the filesystem but that one is not full-proof.
Also if I run the unfreeze command again on an unfrozen filesystem I will get something like this:
xfs_freeze: cannot unfreeze filesystem mounted at /blahblah: Invalid
argument
This method is not fool-proof either because the message is not accurate.
Is there a command I can use that would tell me the freeze status of the filesystem, or is there a fool-proof method that I can use to determine this?
Any hint?
filesystems freeze xfs fsfreeze
add a comment |
up vote
1
down vote
favorite
I use xfs_freeze
to freeze and unfreeze my xfs filesystem:
xfs_freeze -f /blahblah
xfs_freeze -u /blahblah
After I run the unfreeze command I want to make sure that the filesystem is not frozen for sure. This command does not return any value or message.
I know I can try remounting the filesystem but that one is not full-proof.
Also if I run the unfreeze command again on an unfrozen filesystem I will get something like this:
xfs_freeze: cannot unfreeze filesystem mounted at /blahblah: Invalid
argument
This method is not fool-proof either because the message is not accurate.
Is there a command I can use that would tell me the freeze status of the filesystem, or is there a fool-proof method that I can use to determine this?
Any hint?
filesystems freeze xfs fsfreeze
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I use xfs_freeze
to freeze and unfreeze my xfs filesystem:
xfs_freeze -f /blahblah
xfs_freeze -u /blahblah
After I run the unfreeze command I want to make sure that the filesystem is not frozen for sure. This command does not return any value or message.
I know I can try remounting the filesystem but that one is not full-proof.
Also if I run the unfreeze command again on an unfrozen filesystem I will get something like this:
xfs_freeze: cannot unfreeze filesystem mounted at /blahblah: Invalid
argument
This method is not fool-proof either because the message is not accurate.
Is there a command I can use that would tell me the freeze status of the filesystem, or is there a fool-proof method that I can use to determine this?
Any hint?
filesystems freeze xfs fsfreeze
I use xfs_freeze
to freeze and unfreeze my xfs filesystem:
xfs_freeze -f /blahblah
xfs_freeze -u /blahblah
After I run the unfreeze command I want to make sure that the filesystem is not frozen for sure. This command does not return any value or message.
I know I can try remounting the filesystem but that one is not full-proof.
Also if I run the unfreeze command again on an unfrozen filesystem I will get something like this:
xfs_freeze: cannot unfreeze filesystem mounted at /blahblah: Invalid
argument
This method is not fool-proof either because the message is not accurate.
Is there a command I can use that would tell me the freeze status of the filesystem, or is there a fool-proof method that I can use to determine this?
Any hint?
filesystems freeze xfs fsfreeze
filesystems freeze xfs fsfreeze
edited 2 days ago
Rui F Ribeiro
38.5k1479128
38.5k1479128
asked Dec 7 at 0:25
kaptan
1847
1847
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
1
down vote
TL;DR:
While there is no direct way to query if a filesystem is frozen, you can abuse the fact that nested freezing attempts don't work. For example, I have an XFS filesystem mounted at /xfs_test:
[root@testvm1 ~]# mount | grep xfs_test
/dev/sdb1 on /xfs_test type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
[root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Initial freeze
[root@testvm1 ~]# echo $?
0
[root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Subsequent freeze attempt
xfs_freeze: cannot freeze filesystem at /xfs_test/: Device or resource busy
[root@testvm1 ~]# echo $?
1
The same analogy works for un-freezing or thawing the filesystem:
[root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Same filesystem, currently frozen
[root@testvm1 ~]# echo $?
0
[root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Thawed filesystem
xfs_freeze: cannot unfreeze filesystem mounted at /xfs_test/: Invalid argument
[root@testvm1 ~]# echo $?
1
I had to do some digging to find out if the frozen/thawed state query was possible. Although the technical details were a little beyond my understanding, this is what I have put together.
Freezing and thawing a filesystem was a feature initially built for XFS. It was eventually brought forward to the Linux kernel, allowing the functionality to work for other filesystems as well. As this LWN article explains:
Takashi Sato proposes taking an XFS-specific feature and moving it
into the filesystem code. The patch would provide an ioctl() for
suspending write access to a filesystem, freezing, along with a
thawing option to resume writes.
...
Essentially the patch just exports the freeze_bdev() kernel function
in a user accessible way.freeze_bdev() locks a file system into a
consistent state by flushing the superblock and syncing the device.
The patch also adds tracking of the frozen state to the struct
block_device state field.
At this point, nested freezing and thawing were possible. As I understand it, a counter variable in the code kept track of the nested freezing and thawing attempts. The variable would increment when freezing, and decrement when thawing. Only when the counter was 0 would the filesystem actually thaw.
After that, I found this patch discussion from 2016, which is about adding a new ioctl call to query the filesystem's state: fs: add the FIGETFROZEN ioctl call. As far as I can tell, this patch has not been merged into the kernel.
The patch discussion provided a few key points:
And, besides, polling for frozenness from userspace is inherently racy
- by the time the syscall returns, the information may be incorrect, so you can't rely on it for decision making purposes in userspace.
And then:
I [sic] quick dig shows nesting was intentionally broken more than 5
years ago in making the freeze ioctl work on btrfs.
This led me to the, ahem, solution shown above.
Yet another possibility is covered in this answer over at StackOverflow. If you try to remount a filesystem which is frozen, the attempt will fail with a 'device is busy' error. The mount could also be busy for a number of other reasons, so this solution is admittedly not fool-proof.
1
While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause amount -o remount
to fail with-EBUSY
.
– Austin Hemmelgarn
2 days ago
@Haxiel Thanks for digging this up : )
– kaptan
2 days ago
add a comment |
up vote
0
down vote
I think you will have to write your own command that will check.
#!/bin/bash
function touchFs() {
echo "mp: $1";
touch "$1/frzn-5tst";
if [ -f "$1/frzn-5tst" ]; then
rm "$1/frzn-5tst" &> /dev/null;
fi
}
function usage() {
echo "$0 <mountpoint>";
exit 1;
}
if [ -z $1 ]; then
usage;
fi
touchFs $1&
ppid=$!;
state=`ps -o s= -p $ppid`;
if [ -z "$state" ]; then
echo "device is unfrozen";
elif [ "$state" == "S" ]; then
echo "device is frozen";
fi
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
TL;DR:
While there is no direct way to query if a filesystem is frozen, you can abuse the fact that nested freezing attempts don't work. For example, I have an XFS filesystem mounted at /xfs_test:
[root@testvm1 ~]# mount | grep xfs_test
/dev/sdb1 on /xfs_test type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
[root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Initial freeze
[root@testvm1 ~]# echo $?
0
[root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Subsequent freeze attempt
xfs_freeze: cannot freeze filesystem at /xfs_test/: Device or resource busy
[root@testvm1 ~]# echo $?
1
The same analogy works for un-freezing or thawing the filesystem:
[root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Same filesystem, currently frozen
[root@testvm1 ~]# echo $?
0
[root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Thawed filesystem
xfs_freeze: cannot unfreeze filesystem mounted at /xfs_test/: Invalid argument
[root@testvm1 ~]# echo $?
1
I had to do some digging to find out if the frozen/thawed state query was possible. Although the technical details were a little beyond my understanding, this is what I have put together.
Freezing and thawing a filesystem was a feature initially built for XFS. It was eventually brought forward to the Linux kernel, allowing the functionality to work for other filesystems as well. As this LWN article explains:
Takashi Sato proposes taking an XFS-specific feature and moving it
into the filesystem code. The patch would provide an ioctl() for
suspending write access to a filesystem, freezing, along with a
thawing option to resume writes.
...
Essentially the patch just exports the freeze_bdev() kernel function
in a user accessible way.freeze_bdev() locks a file system into a
consistent state by flushing the superblock and syncing the device.
The patch also adds tracking of the frozen state to the struct
block_device state field.
At this point, nested freezing and thawing were possible. As I understand it, a counter variable in the code kept track of the nested freezing and thawing attempts. The variable would increment when freezing, and decrement when thawing. Only when the counter was 0 would the filesystem actually thaw.
After that, I found this patch discussion from 2016, which is about adding a new ioctl call to query the filesystem's state: fs: add the FIGETFROZEN ioctl call. As far as I can tell, this patch has not been merged into the kernel.
The patch discussion provided a few key points:
And, besides, polling for frozenness from userspace is inherently racy
- by the time the syscall returns, the information may be incorrect, so you can't rely on it for decision making purposes in userspace.
And then:
I [sic] quick dig shows nesting was intentionally broken more than 5
years ago in making the freeze ioctl work on btrfs.
This led me to the, ahem, solution shown above.
Yet another possibility is covered in this answer over at StackOverflow. If you try to remount a filesystem which is frozen, the attempt will fail with a 'device is busy' error. The mount could also be busy for a number of other reasons, so this solution is admittedly not fool-proof.
1
While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause amount -o remount
to fail with-EBUSY
.
– Austin Hemmelgarn
2 days ago
@Haxiel Thanks for digging this up : )
– kaptan
2 days ago
add a comment |
up vote
1
down vote
TL;DR:
While there is no direct way to query if a filesystem is frozen, you can abuse the fact that nested freezing attempts don't work. For example, I have an XFS filesystem mounted at /xfs_test:
[root@testvm1 ~]# mount | grep xfs_test
/dev/sdb1 on /xfs_test type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
[root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Initial freeze
[root@testvm1 ~]# echo $?
0
[root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Subsequent freeze attempt
xfs_freeze: cannot freeze filesystem at /xfs_test/: Device or resource busy
[root@testvm1 ~]# echo $?
1
The same analogy works for un-freezing or thawing the filesystem:
[root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Same filesystem, currently frozen
[root@testvm1 ~]# echo $?
0
[root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Thawed filesystem
xfs_freeze: cannot unfreeze filesystem mounted at /xfs_test/: Invalid argument
[root@testvm1 ~]# echo $?
1
I had to do some digging to find out if the frozen/thawed state query was possible. Although the technical details were a little beyond my understanding, this is what I have put together.
Freezing and thawing a filesystem was a feature initially built for XFS. It was eventually brought forward to the Linux kernel, allowing the functionality to work for other filesystems as well. As this LWN article explains:
Takashi Sato proposes taking an XFS-specific feature and moving it
into the filesystem code. The patch would provide an ioctl() for
suspending write access to a filesystem, freezing, along with a
thawing option to resume writes.
...
Essentially the patch just exports the freeze_bdev() kernel function
in a user accessible way.freeze_bdev() locks a file system into a
consistent state by flushing the superblock and syncing the device.
The patch also adds tracking of the frozen state to the struct
block_device state field.
At this point, nested freezing and thawing were possible. As I understand it, a counter variable in the code kept track of the nested freezing and thawing attempts. The variable would increment when freezing, and decrement when thawing. Only when the counter was 0 would the filesystem actually thaw.
After that, I found this patch discussion from 2016, which is about adding a new ioctl call to query the filesystem's state: fs: add the FIGETFROZEN ioctl call. As far as I can tell, this patch has not been merged into the kernel.
The patch discussion provided a few key points:
And, besides, polling for frozenness from userspace is inherently racy
- by the time the syscall returns, the information may be incorrect, so you can't rely on it for decision making purposes in userspace.
And then:
I [sic] quick dig shows nesting was intentionally broken more than 5
years ago in making the freeze ioctl work on btrfs.
This led me to the, ahem, solution shown above.
Yet another possibility is covered in this answer over at StackOverflow. If you try to remount a filesystem which is frozen, the attempt will fail with a 'device is busy' error. The mount could also be busy for a number of other reasons, so this solution is admittedly not fool-proof.
1
While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause amount -o remount
to fail with-EBUSY
.
– Austin Hemmelgarn
2 days ago
@Haxiel Thanks for digging this up : )
– kaptan
2 days ago
add a comment |
up vote
1
down vote
up vote
1
down vote
TL;DR:
While there is no direct way to query if a filesystem is frozen, you can abuse the fact that nested freezing attempts don't work. For example, I have an XFS filesystem mounted at /xfs_test:
[root@testvm1 ~]# mount | grep xfs_test
/dev/sdb1 on /xfs_test type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
[root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Initial freeze
[root@testvm1 ~]# echo $?
0
[root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Subsequent freeze attempt
xfs_freeze: cannot freeze filesystem at /xfs_test/: Device or resource busy
[root@testvm1 ~]# echo $?
1
The same analogy works for un-freezing or thawing the filesystem:
[root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Same filesystem, currently frozen
[root@testvm1 ~]# echo $?
0
[root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Thawed filesystem
xfs_freeze: cannot unfreeze filesystem mounted at /xfs_test/: Invalid argument
[root@testvm1 ~]# echo $?
1
I had to do some digging to find out if the frozen/thawed state query was possible. Although the technical details were a little beyond my understanding, this is what I have put together.
Freezing and thawing a filesystem was a feature initially built for XFS. It was eventually brought forward to the Linux kernel, allowing the functionality to work for other filesystems as well. As this LWN article explains:
Takashi Sato proposes taking an XFS-specific feature and moving it
into the filesystem code. The patch would provide an ioctl() for
suspending write access to a filesystem, freezing, along with a
thawing option to resume writes.
...
Essentially the patch just exports the freeze_bdev() kernel function
in a user accessible way.freeze_bdev() locks a file system into a
consistent state by flushing the superblock and syncing the device.
The patch also adds tracking of the frozen state to the struct
block_device state field.
At this point, nested freezing and thawing were possible. As I understand it, a counter variable in the code kept track of the nested freezing and thawing attempts. The variable would increment when freezing, and decrement when thawing. Only when the counter was 0 would the filesystem actually thaw.
After that, I found this patch discussion from 2016, which is about adding a new ioctl call to query the filesystem's state: fs: add the FIGETFROZEN ioctl call. As far as I can tell, this patch has not been merged into the kernel.
The patch discussion provided a few key points:
And, besides, polling for frozenness from userspace is inherently racy
- by the time the syscall returns, the information may be incorrect, so you can't rely on it for decision making purposes in userspace.
And then:
I [sic] quick dig shows nesting was intentionally broken more than 5
years ago in making the freeze ioctl work on btrfs.
This led me to the, ahem, solution shown above.
Yet another possibility is covered in this answer over at StackOverflow. If you try to remount a filesystem which is frozen, the attempt will fail with a 'device is busy' error. The mount could also be busy for a number of other reasons, so this solution is admittedly not fool-proof.
TL;DR:
While there is no direct way to query if a filesystem is frozen, you can abuse the fact that nested freezing attempts don't work. For example, I have an XFS filesystem mounted at /xfs_test:
[root@testvm1 ~]# mount | grep xfs_test
/dev/sdb1 on /xfs_test type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
[root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Initial freeze
[root@testvm1 ~]# echo $?
0
[root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Subsequent freeze attempt
xfs_freeze: cannot freeze filesystem at /xfs_test/: Device or resource busy
[root@testvm1 ~]# echo $?
1
The same analogy works for un-freezing or thawing the filesystem:
[root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Same filesystem, currently frozen
[root@testvm1 ~]# echo $?
0
[root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Thawed filesystem
xfs_freeze: cannot unfreeze filesystem mounted at /xfs_test/: Invalid argument
[root@testvm1 ~]# echo $?
1
I had to do some digging to find out if the frozen/thawed state query was possible. Although the technical details were a little beyond my understanding, this is what I have put together.
Freezing and thawing a filesystem was a feature initially built for XFS. It was eventually brought forward to the Linux kernel, allowing the functionality to work for other filesystems as well. As this LWN article explains:
Takashi Sato proposes taking an XFS-specific feature and moving it
into the filesystem code. The patch would provide an ioctl() for
suspending write access to a filesystem, freezing, along with a
thawing option to resume writes.
...
Essentially the patch just exports the freeze_bdev() kernel function
in a user accessible way.freeze_bdev() locks a file system into a
consistent state by flushing the superblock and syncing the device.
The patch also adds tracking of the frozen state to the struct
block_device state field.
At this point, nested freezing and thawing were possible. As I understand it, a counter variable in the code kept track of the nested freezing and thawing attempts. The variable would increment when freezing, and decrement when thawing. Only when the counter was 0 would the filesystem actually thaw.
After that, I found this patch discussion from 2016, which is about adding a new ioctl call to query the filesystem's state: fs: add the FIGETFROZEN ioctl call. As far as I can tell, this patch has not been merged into the kernel.
The patch discussion provided a few key points:
And, besides, polling for frozenness from userspace is inherently racy
- by the time the syscall returns, the information may be incorrect, so you can't rely on it for decision making purposes in userspace.
And then:
I [sic] quick dig shows nesting was intentionally broken more than 5
years ago in making the freeze ioctl work on btrfs.
This led me to the, ahem, solution shown above.
Yet another possibility is covered in this answer over at StackOverflow. If you try to remount a filesystem which is frozen, the attempt will fail with a 'device is busy' error. The mount could also be busy for a number of other reasons, so this solution is admittedly not fool-proof.
answered 2 days ago
Haxiel
816310
816310
1
While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause amount -o remount
to fail with-EBUSY
.
– Austin Hemmelgarn
2 days ago
@Haxiel Thanks for digging this up : )
– kaptan
2 days ago
add a comment |
1
While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause amount -o remount
to fail with-EBUSY
.
– Austin Hemmelgarn
2 days ago
@Haxiel Thanks for digging this up : )
– kaptan
2 days ago
1
1
While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause a
mount -o remount
to fail with -EBUSY
.– Austin Hemmelgarn
2 days ago
While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause a
mount -o remount
to fail with -EBUSY
.– Austin Hemmelgarn
2 days ago
@Haxiel Thanks for digging this up : )
– kaptan
2 days ago
@Haxiel Thanks for digging this up : )
– kaptan
2 days ago
add a comment |
up vote
0
down vote
I think you will have to write your own command that will check.
#!/bin/bash
function touchFs() {
echo "mp: $1";
touch "$1/frzn-5tst";
if [ -f "$1/frzn-5tst" ]; then
rm "$1/frzn-5tst" &> /dev/null;
fi
}
function usage() {
echo "$0 <mountpoint>";
exit 1;
}
if [ -z $1 ]; then
usage;
fi
touchFs $1&
ppid=$!;
state=`ps -o s= -p $ppid`;
if [ -z "$state" ]; then
echo "device is unfrozen";
elif [ "$state" == "S" ]; then
echo "device is frozen";
fi
add a comment |
up vote
0
down vote
I think you will have to write your own command that will check.
#!/bin/bash
function touchFs() {
echo "mp: $1";
touch "$1/frzn-5tst";
if [ -f "$1/frzn-5tst" ]; then
rm "$1/frzn-5tst" &> /dev/null;
fi
}
function usage() {
echo "$0 <mountpoint>";
exit 1;
}
if [ -z $1 ]; then
usage;
fi
touchFs $1&
ppid=$!;
state=`ps -o s= -p $ppid`;
if [ -z "$state" ]; then
echo "device is unfrozen";
elif [ "$state" == "S" ]; then
echo "device is frozen";
fi
add a comment |
up vote
0
down vote
up vote
0
down vote
I think you will have to write your own command that will check.
#!/bin/bash
function touchFs() {
echo "mp: $1";
touch "$1/frzn-5tst";
if [ -f "$1/frzn-5tst" ]; then
rm "$1/frzn-5tst" &> /dev/null;
fi
}
function usage() {
echo "$0 <mountpoint>";
exit 1;
}
if [ -z $1 ]; then
usage;
fi
touchFs $1&
ppid=$!;
state=`ps -o s= -p $ppid`;
if [ -z "$state" ]; then
echo "device is unfrozen";
elif [ "$state" == "S" ]; then
echo "device is frozen";
fi
I think you will have to write your own command that will check.
#!/bin/bash
function touchFs() {
echo "mp: $1";
touch "$1/frzn-5tst";
if [ -f "$1/frzn-5tst" ]; then
rm "$1/frzn-5tst" &> /dev/null;
fi
}
function usage() {
echo "$0 <mountpoint>";
exit 1;
}
if [ -z $1 ]; then
usage;
fi
touchFs $1&
ppid=$!;
state=`ps -o s= -p $ppid`;
if [ -z "$state" ]; then
echo "device is unfrozen";
elif [ "$state" == "S" ]; then
echo "device is frozen";
fi
edited 2 days ago
answered 2 days ago
NiteRain
1104
1104
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f486484%2fhow-to-determine-freeze-unfreeze-status-of-a-filesystem%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown