2016년 10월 18일 화요일

작은 윈도우 배치 파일 만들기 - 변수,부모디렉토리,아규먼트전달

오랜만에 작은 윈도우 배치 파일을 만들 일이 있어서 그 결과를 공유한다.

1.
@ECHO OFF 말고는 생각이 안나서 일단 검색을 해보니 한글 블로그도 있고, 위키피디아도 있지만 세번째 검색결과로 나온 외국 개발자의 블로그가 오버뷰로 제일 볼만한 것 같다.

2.
윈도우 배치 파일에서는 SET 변수명=값 으로 변수를 설정하고, %변수명%으로 변수를 사용한다. 주의해야할 점은 리눅스와 달리 값을 쌍따옴표로 묶으면 쌍따옴표가 그대로 값으로 사용된다.

```
SET JAVA_OPTIONS="-Xms128M -Xmx512M -Xmx1024M"
java %JAVA_OPTIONS%        ===> java "-Xms128M -Xmx512M -Xmx1024M"
SET JAVA_OPTIONS=-Xms128M -Xmx512M -Xmx1024M
java %JAVA_OPTIONS%        ===> java -Xms128M -Xmx512M -Xmx1024M
```

3.
배포중인 어플리케이션의 구조가 /bin, /conf, /lib 와 같은 구조라서 실행파일의 부모디렉토리까지의 경로가 필요한데, 이것도 검색을 통해 아래처럼 구현했다.

```
for %%i in ("%~dp0..") do set "parent=%%~fi"
SET APP_PATH=%parent%
```

4.
배치 파일에 입력된 아규먼트를 갯수와 상관없이 그대로 사용하고자 할 때는 %* 를 사용하면 된다.

2016년 10월 6일 목요일

Java에서 Exabyte 급의 File System의 Free Space 구하기

특정 디렉토리가 속한 파일 시스템의 전체 용량과 사용가능한 용량을 주기적으로 체크해서 데이터베이스에 기록하는 프로그램이 있다. 처음 개발한 이후로 2년여 동안 별다른 문제가 없었는데, 지난주에 AWS에 배포된 시스템에서 문제가 생겼다.

전체 용량이 -999999999999999 비슷한 수의 음수로 저장되고 있었다. 로그를 확인해보니 시스템이 계산한 전체 용량은 -9223372036854775808 이었다. 이 또한 무슨 일인지?

시스템에서 df로 확인해 보았더니, 전체 용량이 8 EB였다. 이건 자바의 long 데이터타입의 최대값을 벗어나는 값이다.

[ec2-user@hostname]$ df
Filesystem                                                  1K-blocks      Used        Available Use% Mounted on
xxx.amazonaws.com:/ 9007199254740992 238655488 9007199016085504   1% /efs

찾아보니 프로그램에서 사용한 자바의 File 클래스의 getTotalSpace 메서드의 리턴이 long이고, 이 메서드가 음수를 리턴하고 있었다. 조금더 검색해보니 이미 2016년 7월 26일에 버그로 리포팅된 내용이었다. 여기여기에서 확인이 가능하다. 내용을 보면 리눅스는 64-bit의 unsigned integer 2개로 블록사이즈와 블록갯수로 파일시스템의 용량을 표현하는데 자바는 이걸 곱한 값을 64-bit signed long으로 리턴한다는 것이다.

버그가 고쳐지길 기다릴 수는 없기에 검색을 해보니 apache common io 라이브러리가 만들어놓은 FileSystemUtils 클래스의 freeSpaceKB 메서드가 있었다. 설명을 읽어보니 내부적으로 리눅스의 df 명령의 결과를 파싱해서 리턴하는 것 같다. 그래도 KB로 리턴하니까 overflow는 발생하지 않을 것 같다.

그런데 사용가능한 용량외에도 전체 용량도 KB단위로 리턴하는 메서드가 필요한데 그것은 아무리 찾아봐도 나오지가 않는다.

결국 자체적으로 df를 파싱해서 전체 용량과 사용가능한 용량을 구해야 할 것 같다. 그리고 이 기능은 df가 가능한 리눅스에서만 정상적으로 동작할 것이다.